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I.  INTRODUCTION 


A.  PURPOSE 

In  1981  the  Coast  Guard  contracted  for  a  service-wide  standard  microcomputer 
capability  and  its  support.  That  contract  is  about  to  expire.  In  the  interest  of 
continuing  to  provide  the  Coast  Guard  with  the  microcomputer  capabilities  and 
support  which  have  become  an  integral  part  of  Coast  Guard  operations  and  support, 
procurement  of  hardware,  software,  maintenance,  training  and  other  support  services 
must  be  completed  prior  to  the  expiration  of  the  current  contract.  The  following 
excerpt  from  a  Coast  Guard  policy  document  describes  the  need  for  this  thesis: 


The  original  standard  terminal  contract  was  extremely  difficult  to  manage  for  the 
first  vear  and  a  half,  mostlv  due  to  the  Coast  Guard  s  inexperience  with"  an  ADP 
procurement  that  reached  s'o  deeplv  into  the  organization.  This  was  the  first  time 
ADP  capabilitv  was  made  available  to  the  majoritv  of  the  Coast  Guard,  and  the 
contract  provisions  were  not  adequate  to  ensure  sufficient  support  to  the  user. 
To  avoid  similar  problems  in  the  administration  of  the  follow'-on  contract,  the 
project  staff  shall  place  a  heavy  emphasis  on  seeking  lessons  learned  in  the  past, 
ancf  incorporating  them  into  the  strategy  of  the  new  procurement.  Experts  in 
many  functional  areas  must  be  involved"  such  as  G-FCP  (Office  of  Comptroller, 
Procurement  Division),  G-FQA  (Office  of  Comptroller.  Qualitv  Assurance 
Division).  G-PTE  (Office  of  Personnel,  Training  and  Education  Division),  G-TDS 
(Office  of  Command.  Control  and  Communications,  Data  Svstems  Division!.  G- 
TES  (Office  of  Command,  Control  and  Communications,  Electronics  Division), 
SMEF  (Svstems  Management  and  Engineering  Facilitv)  and  all  Operating,  and 
Support  Program  Managers.  In  addition,  involvement  "of  persons  with  first “hand 
knowledge  of  the  problems  in  the  original  contract  would  help  to  avoid  the  same 
problems  the  second  time  around.  [Ref.  1:  p.  STMP-20] 


This  thesis  will  attempt  to  satisfy  the  lessons  learned  requirement  from  the  Data 
Systems  Division  (G-TDS)  Project  Officer's  point  of  view.  Finally,  the  policy 
statement  quoted  above  is  stated  in  a  very  negative  wray.  It  suggests  that  the  earlier 
problems  should  be  avoided.  However,  it  makes  no  mention  of  the  strengths  and 
positive  points  of  the  original  acquisition.  In  the  conclusions  portion  of  this  thesis,  the 
strengths  to  be  emphasized  as  w'ell  as  the  problems  to  be  avoided  will  be  discussed. 

B.  METHODOLOGY 

An  extensive  literature  search  of  applicable  Department  of  Transportation,  Coast 
Guard,  General  Services  Administration,  and  Office  of  Management  and  Budget 
regulations,  orders  and  directives  wras  performed  to  determine  the  acquisition  process 
prescribed  for  ADP  resources  To  provide  insight  into  the  original  standard  terminal 


acquisition  process,  interviews  and  questionnaires  were  used  to  obtain  information 
from  the  participants  in  that  project.  Questionnaires  from  other  studies  on  the 
standard  terminal  were  also  used.  The  members  involved  with  the  current  project  for 
recompetition  of  the  Coast  Guard  standard  terminal  provided  an  extraordinary  amount 
of  knowledge  of  and  insight  into  the  acquisition  process.  Although  a  significant 
amount  of  the  original  life  cycle  documentation  for  the  first  project  was  not  located  in 
the  acquisition  file,  the  interviews  have  provided  substantial  information  toward  filling 
documentation  gaps. 

Comparison  of  the  original  standard  terminal  acquisition  with  the  current 
regulations  may  seem  like  an  unfair  and  meaningless  evaluation.  However,  this  thesis 
was  prepared  in  that  very  manner  for  several  reasons.  First,  obtaining  the  applicable 
regulations  as  they  existed  at  the  time  of  the  original  acquisition  would  be  a  significant 
if  not  impossible  research  task.  Next,  microcomputers  were  a  relatively  new 
technology  bursting  onto  the  scene  at  that  time,  and  their  impact  was  not  completely 
evaluated  or  anticipated  by  those  organizations  that  mandate  regulations  and  establish 
procedures.  Some  of  the  directives  and  regulations  did  not  even  exist  at  the  time  of  the 
original  acquisition.  -Finally,  the  intent  of  this  thesis  is  to  provide  a  constructive 
lessons  learned'  type  of  evaluation  approach,  to  avoid  the  pitfalls  and  emphasize  the 
strengths  of  our  past  efforts.  This  thesis  will  provide  an  acquisition  model  upon  which 
acquisition  planners  and  managers  can  use  to  base  similar  acquisitions. 

Following  the  current  applicable  rules  and  regulations  while  avoiding  the 
problems  of  the  past  should  be  a  major  goal  for  any  type  of  acquisition  undertaken  by 
the  Coast  Guard. 

C.  THESIS  ORGANIZATION 

•  CHAPTER  I.  Introduction  -  A  description  of  the  thesis. 

•  CHAPTER  II.  Background  -  The  reasons  behind  the  acquisition  of  the  Coast 
Guard  Standard  Terminal. 

•  CHAPTER  III.  Budgeting.-  A  tip  of  the  iceberg  introduction  to  the  Coast 
Guard  planning,  programming  and  budgeting  svstem  for  command,  control  and 
commumcations/mformation  resources  management  (C3,iRM). 

•  CHAPTER  IV.  Acquisition  Framework  -  The  significant  elements  that 
comprise  the  acquisition  process  for  ADP  resources  are  each  briefiv  described  in 
the  early  sections  of  this  chapter.  Developing  an  acquisition  model  bv  putting 
these  elements  together  is  the  purpose  of  tne  final  section. 

•  CHAPTER  V.  Acquisition  -  The  actual  acquisition  process  used  bv  the  Coast 
Guard  for  the  standard  terminal. 

•  CHAPTER  VI.  Conclusions  and  Recommendations  -  Brief  discussions  of 
significant  points  considered  as  a  result  of  research  into  the  standard  terminal 
acquisition  process. 


APPENDICES  *  Enclosures  taken,  from  numerous  government  sources  on  the 
contents  and  preparation  of  acquisition  documentation  and  reports. 

JjISTo^FJR^reR£N'CES  -  A  sequential  list  of  sources  cited  or  paraphrased  in 

BIBLIOGRAPHY  -  Selected  sources  which  proved  helpful  in  the  research 
process. 


II.  BACKGROUND 


During  the  late  1970's  the  Coast  Guard  began  developing  what  was  later  to 
become  the  U.S.  Coast  Guard  Information  Resources  Management  Architecture.  The 
plan  was  based  on  the  following  goals  [Ref.  2:  p.  2-2J: 

•  Intelligent  Terminals  to  provide  a  vehicle  for  local  processing,  orieinal  data 

entry,  and  access  to  the  network!  s) 

•  The  Communications  Network  to  provide  connectivity 

•  Data  Base  Technology  to  control  the  data  resource 

•  Integration  of  the  parts  into  a  whole.  The  parts  are: 

a.  Plans 

b.  Budgetary  Action 

c.  Human  resources  ( including  training) 

d.  Applications  software  to  perform  specific  tasks 

e.  Standard  software  packages  to  provide  common  user  capabilities  and 
interfaces 

f.  Support  facilities  such  as  Coast  Guard  laboratories  and  Supplv  Center  to 
provide  unique  services  such  as  hardware  and  software  support. ' 

The  standard  terminal  became  the  intelligent  terminal,  one  of  the  building  blocks, 
upon  which  the  architecture  plan  is  based.  A  contract  for  communications  network 
services  was  let  during  FY80,  one  year  before  the  standard  terminal  contract.  A  5  year 
service  contract  with  GTE  Telenet  provided  the  telecommunications  medium  along 
with  other  Government  networks.  The  standard  terminal  hardware  and  software 
provided  the  local  networking  capability. 

Data  base  technology,  another  major  part  of  the  plan,  refers  to  the  concept  that 
every  user  does  not  require  that  his  her  data  be  stored  and/or  maintained  locally. 
Rather,  the  data  may  be  available  at  another  source  where  it  is  entered  or  maintained. 
Ideally,  the  technology  and  methods  to  access  that  data  would  be  transparent  to  the 
user.  Providing  access  to  data  in  central  databases  allows  a  practical  and  economical 
means  to  insure  data  integrity.  Every  user  does  not  require  a  separate  copy  of  the 
database  or  the  resources  (time,  personnel,  machine,  money)  to  maintain  current  and 
accurate  data.  The  goal  that  data  need  only  be  entered  once  and  eventually 
maintained  by  a  single  activity,  benefits  the  Coast  Guard  as  a  whole.  The  Joint 
Uniform  Military  Pay  System  (JUMPS)  is  a  prime  example.  JUMPS  has  a  central 


database  where  pay  data  is  stored  and  maintained  on  Coast  Guard  members. 
References  to  pay  are  all  done  through  the  central  database. 

The  basic  goal  of  the  IRM  architecture  is  to  promote  resource  sharing.  Figure 
2.1,  reproduced  from  Commandant  Instruction  M 3090.1,  is  a  diagram  depicting  the 
IRM  architecture.  It  shows  the  capabilities  and  methods  available  to  the  Coast  Guard 
for  information  transfer  and  access. 

Clusters  of  standard  terminals  are  spread  throughout  the  architecture  as  end 
user's  tools.  They  are  represented  as  terminals  in  the  diagram. 

The  information  centers  at  Coast  Guard  Headquarters  and  District  offices  are 
tasked  with  carrying  out  support  functions  for  users.  The  support  includes 
recommending  use  of  the  proper  hardware  and  software,  enforcing  standards,  and 
dealing  with  common  user  problems  and  requests,  to  name  a  few. 

The  networks  displayed  on  the  diagram  are  the  primary  method  of  data  transfer 
utilized  by  the  Coast  Guard.  AUTODIN,  DDN  (Defense  Digital  Network)  and 
NADIN  (Federal  Aviation  Administration's  National  Airspace  Data  Interchange 
Network)  are  Government  networks.  Public  networks  include  FTS,  the  public  switched 
network  (telephones),  and  the  value  added  network  of  GTE  Telenet.  Coast  Guard 
leased  lines  are  dedicated  data  lines  still  used  in  some  applications.  The  polled  network 
is  used  for  low  to  medium  speed  store  and  forward  communications.  Store  and 
forward  communications  are  most  common  in  the  message  traffic  system,  where 
messages  may  be  sent  from  unit  to  unit. 

A  prime  example  of  a  system  complying  with  the  IRM  architecture  is  the  Marine 
Safety  Information  System  (MSIS).  It  is  depicted  on  the  architecture  diagram.  MSIS 
is  one  of  the  major  applications  that  drove  the  standard  terminal  requirements  in  its 
early  planning  stages.  It  is  a  system  built  around  an  extensive  base  of  information 
about  commercial  vessels  and  marine  safety.  It  provides  licensing,  inspection  and 
documentation  information  nationwide.  Standard  terminals  connect  Headquarters, 
District  offices,  Marine  Safety  Offices  (MSO),  Captain  of  the  Port  offices  (COTP), 
Marine  Inspection  Offices  (MIO)  and  Marine  Safety  Detachments  (MSD)  to  the  MSIS 
host  via  networks.  Other  major  applications  such  as  JUMPS  (Joint  Uniform  Military 
Pay  System)  and  PM  IS  (Personnel  Management  Information  System),  for  example, 
exist  and  utilize  the  IRM  architecture  in  the  same  manner  as  MSIS. 

Coast  Guard  units  include  airstations.  MSO's.  groups,  coastal  search  and  rescue 
stations,  communications  centers,  cutters  and  aircraft.  Clusters  of  standard  terminals 


are  typically  found  at  most  units.  Clusters  allow  interconnection  of  offices  and 
divisions  at  those  units. 

A  major  goal  of  the  Coast  Guard  C3/IRM  is  to  maintain  horizontal  and  vertical 
compatibility  of  its  1RM  resources.  Horizontal  compatibility  means  the  ability  of 
information  to  be  used  from  station  to  station,  from  unit  to  unit.  Vertical 
compatibility  is  being  able  to  pass  information  from  smaller  subordinate  units  to  larger 
higher  level  units.  The  reverse  is  also  desired. 

The  standard  terminal  was  originally  intended  to  be  a  Coast  Guard  wide  standard 
data  entry  terminal.  ADP  capability  was  centralized  in  large  facilities  at  that  time. 
Use  of  a  single,  easily  recognizable,  piece  of  hardware  would  reduce  the  training  and 
familiarization  time  necessary  for  personnel  using  those  ADP  facilities. 


If  all  access  equipment  is  configured  with  standard  modules,  if  the  method  of 
discoursing  with  the  computer  is  the  same,  and  if  the  method  of  computer  data 
displav  is  common  throughout  all  computer  facilities  and  applications,  then  the 
problem  of  multiple  ADP  facilities  and  vendors  does  not  affect  the  user.  If  the 
user  sees  a  consistent  access  scheme  on  a  computer  terminal  displav  screen,  and 
discusses  and  enters  data  to  all  computers  in  a  consistent  format,  he  or  she  need 
not  be  concerned  about  the  make,  model,  or  location  of  the  computer  being 
accessed.  [Ref.  3:  Sec.  F.  1.2.2] 

The  standard  terminal  was  developed  into  a  high  capability  microcomputer  with  the 
ability  to  satisfy  most  of  the  Coast  Guard’s  needs  at  that  point  in  time  and  well  into 
the  future. 

Office  automation  was  not  a  buzz  word  during  the  late  1970's  when  the 
requirements  for  the  standard  terminal  were  developed.  The  Coast  Guard  built  office 
automation  capabilities  into  its  contract  when  it  decided  that  local  w’ord  processing, 
telecommunications,  and  local  networking  should  be  requirements  for  its  systems. 
Local  networking  (clustering)  gives  several  workstations  in  a  relatively  close  area  the 
ability  to  share  peripheral  devices  and,  most  importantly,  share  data. 
Telecommunications  allow  remote  data  entry  and  data  transfer  between  clusters,  and 
from  workstations  to  larger  ADP  facilities. 

Applications  development  software  such  as  Pascal,  Cobol  and  Fortran  were 
included  on  the  specification.  Others,  such  as  database  capabilities,  for  local  data  entry 
and  manipulation  were  also  required.  Each  site  had  a  standard  set  of  software 
delivered  with  its  hardware. 


U.S.  Coast  Guard  Information 
Resources  Management  Architecture 


[Ref.  2:  p.  2--JJ 


Figure  2.1  Information  Resources  Management  Architecture. 


III.  BUDGETING 


Budgeting  for  any  large  project  is  a  process  that  must  begin  well  in  advance  of 
the  time  that  funds  will  actually  be  obligated  for  that  project.  This  chapter  will  provide 
an  overview  of  the  planning,  programming  and  budgeting  system  the  Coast  Guard  s 
Office  of  Command,  Control,  and  Communications  (G-T)  uses  for  information 
resources  management  (IRM)  resources. 

The  Commandant  has  responsibility  for  an  approved  Coast  Guard  program.  The 
Chief  of  Staff  at  headquarters  coordinates  the  activities  of  program  directors,  who  rely 
on  program  managers,  to  develop  the  various  programs  that  support  the  basic 
objectives  of  the  Coast  Guard  [Ref.  4:  p.  1-2]: 

•  To  minimize  loss  of  life,  personal  injurv  and  propertv  damage  on,  over,  and 
under  the  high  seas  and  waters  subject  to  Li. S. 'jurisdiction. 

•  To  facilitate  waterborne  activities  in  support  of  national  economic,  scientific, 
defense  and  social  needs. 

•  To  maintain  an  effective,  ready,  armed  force  prepared  for  and  immediately 
responsive  to  specific  tasks  in  time  or  war  or  emergency.  • 

•  To  assure  the  safety  and  security-1  of  vessels  and  of  ports  and  waterways  and 
their  related  facilities. 

•  To  enforce  federal  laws  and  international  agreements  on  and  under  waters 
subject  to  the  jurisdiction  of  the  United  States''  and  on  and  under  the  high  seas 
where  authorized. 

•  To  maintain  or  improve  the  quality  of  the  marine  environment.  . 

•  To  cooperate  with  other  governmental  agencies  and  entities  (federal,  state  and 
local)  to  assure  efficient  utilization  or  public  resources  and  to  carry  out 
activities  in  the  international  sphere  where  appropriate  in  furthering  national 
policy. 

General  policy  guidance  is  provided  for  the  next  25  years  by  the  Commandant's 
Long  Range  View.  Future  Coast  Guard  missions  and  activities  are  anticipated  through 
the  forecasts  provided  in  the  document.  Headquarters  and  field  level  planning  are  all 
based  upon  the  Commandant's  forecasts.  The  Long  Range  View,  however,  is  not  a 
plan,  it  is  a  policy  statement. 

Requirements  from  which  the  Coast  Guard  develops  its  budget  come  from  many 
sources.  Figure  3.1  illustrates  the  inputs  to  the  planning  database. 

Operating  program  plans  and  support  program  plans  are  extracted  from  the 
Commandant's  Long  Range  View.  With  this  extraction,  planning  is  brought  down  to  a 
more  manageable  time  frame  of  5  years.  Operating  program  plans  (OPP)  and  support 


program  plans  (SPP)  are  developed  by  operating  and  support  program  managers. 
Operating  program  managers  are  those  officers  overseeing  programs  such  as  search  and 
rescue  (SAR)  and  enforcement  of  laws  and  treaties  (ELT)  which  make  up  the  various 
missions  that  the  Coast  Guard  performs.  Support  programs  are  those  programs  that 
support  the  missions  of  the  Coast  Guard,  such  as  telecommunications  and  engineering. 

It  is  at  the  program  director/manager  levels  that  policy  is  converted  into  plans, 
programs  and  budgets.  Command,  control  and  communications  is  one  of  the  Coast 
Guard  support  programs.  As  mentioned  earlier,  a  five  year  support  program  plan 
(SPP)  is  used  to  translate  formal  Coast  Guard  objectives  into  programs.  The  program 
director  for  this  support  program  is  the  Chief,  Office  of  Command,  Control. and 
Communications  (G-T).  His  deputy  office  chief  (G-Td)  is  the  program  manager  for 
command,  control  and  communications  programs. 

District  Commanders  and  Commanding  Officers  of  headquarters  units  also  take 
the  Commandant's  forecasts  and  translate  them  into  planning  proposals  (PP), 
development  plans  (DP).  Letters  with  recommendations  and  suggestions  may  also  be 
used  to  provide  input  to  the  requirements  database.  Planning  proposals  are  the  initial 
input  for  submitting  a  field  originated  project  into  the  planning,  programming  and 
budget  system.  Approval  of  a  planning  proposal  shows  that  the  project  is  of 
significant  importance  to  proceed  to  the  resource  change  proposal  (RCP)  phase. 
RCP's  are  budget  requests.  They  will  be  discussed  later  in  this  section. 

Requirements  for  information  resources  management  resources  are  described  in 
terms  of  functions,  processes,  activities,  information  requirements,  and  entities  which 
define  the  anticipated  system.  ADP  systems  should  also  oe  submitted  to  the  Coast 
Guard  ADP  Plan,  which  is  input  to  the  ADP  obligation  ceilings  set  for  the  various 
agencies  of  the  federal  government  by  the  Office  of  Management  and  Budget. 

Coast  Guard  requirements  come  from  several  other  sources.  The  Departments  of 
Defense  and  Transportation  may  provide  suggestions  or  direction  to  the  Coast  Guard. 
Research  and  technology  from  outside  the  Coast  Guard  are  external  sources  of  input. 

Figure  3.2  graphically  shows  the  process  which  is  followed  to  develop  C3TR.M 
requirements  into  approved  budget  items. 

C3/IRM  requirements  from  the  planning  database  are  forwarded  to  the  Office  of 
Command,  Control,  and  Communications,  Planning  and  Policy  Division  (G-TPP).  The 
Coast  Guard  C3/1RM  Plan  is  developed  from  that  data.  The  C3  IRM  Plan  addresses 
the  applicable  requirements  which  may  have  come  from  shorter  time  frame  support 


plans.  Coast  Guard  goals  and  strategies  for  command,  control  and 
communications/information  resources  management  for  the  next  20  years  are  outlined 
in  the  C3/IRM  Plan. 

The  direction  in  the  C3/IRM  Plan  provides  input  to  the  Coast  Guard  ADP  Plan 
and  is  the  source  of  the  C3  Support  Plan  (GAT  SPP)  which  describes  the  proposed 
ADP  and  telecommunications  systems  for  the  next  5  year  time  frame.  Systems 
requiring  research  and  development  effort  are  input  to  the  R&D  Support  Program  Plan 
(GRD  SPP).  Others  are  passed  to  the  C3  requirements  document  which  provides 
detailed  schedules  for  replacement  and  acquisitions  of  new  capital  resources. 

Budget  requests  are  submitted  in  the  form  of  resource  change  proposals  (RCP). 
Besides  cost  estimates  the  RCP  includes  information  on  personnel  resources  which  will 
be  required,  expected  benefits  and  impact  on  other  programs.  Three  different  funding 
types  are:  (1)  operating  expenses  (OE)  are  the  funds  with  which  the  Coast  Guard 
carries  out  its  activities  during  the  budget  year;  (2)  acquisition,  construction,  and 
improvement  (AC&I),  multiyear  funding  for  large  projects  and  capital  investments;  and 
(3)  research,  development,  test  and  evaluation  (RDT&E),  research  and  development 
projects.  Some  requirements  will  automatically  have  RCP's  approved.  Others, 
however,  will  require  determinations,  prioritized  justifications,  be  prepared  by  the 
responsible  program  manager.  The  Commandant  later  decides  which  of  these  become 
RCP's.  Approved  RCP's  are  then  used  tq  formulate  the  Coast  Guard  budget. 


Figure  3.1  Coast  Guard  Long  Range  Planning. 


Figure  3.2  Budget  Process  for  C3  IRM. 
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IV.  ACQUISITION  FRAMEWORK 


This  chapter  describes  several  of  the  most  important  topics  concerning  large 
ADP  acquisitions.  They  are  the  ADP  Plan,  the  Department  of  Transportation's 
implementation  of  the  Office  of  Management  and  Budget's  A- 109  acquisition  process 
for  major  systems,  the  secretarial  review  process  for  acquisitions  of  significant  interest 
to  DOT,  and  the  procurement  authority  for  ADP  resources.  Although  it  is  improbable 
that  a  Coast  Guard  ADP  acquisition  would  meet  the  life  cycle  cost  or  R&D  cost 
criteria  of  a  major  system,  a  discussion  of  the  A- 109  process  is  important.  A  secretarial 
review  designation  may  require  the  acquisition  be  done  following  a  scaled  down  A- 109 
process. 

Following  a  brief  presentation  of  the  topics  mentioned  above,  an  acquisition 
model  is  proposed.  The  model  is  to  be  used  by  the  team  involved  with  overseeing  the 
acquisition.  Those  involved  with  particular  projects  along  the  way  will  be  concerned 
with  their  process  in  much  greater  detail,  therefore  the  overall  acquisition  model  will 
not  be  of  particular  benefit  to  them.  However,  everyone  involved  with  the  acquisition 
should  be  aware  of  the  major  project  milestones  and  how  those  milestones  can  be 
affected  by  their  progress  and  efforts. 

A.  ADP  PLAN 

Planning  for  ADP  resources  in  the  Coast  Guard  is  accomplished  by  reporting 
ADP  systems  and  proposals  in  the  Coast  Guard  ADP  Plan.  The  ADP  Plan  provides  a 
near  to  mid  term  planning  horizon  as  to  where  the  Coast  Guard  should  or  will  be  in 
terms  of  ADP  systems  and  capabilities  in  the  next  5-10  years.  Reporting  of  all  ADP 
requirements  is  mandatory,  regardless  of  the  system  cost.  Larger  systems  that  are 
being  developed  will  be  reported  in  the  ADP  Plan  over  a  number  of  years,  beginning 
with  its  concept  formulation,  continuing  through  its  implementation.  Submissions  to 
the  ADP  Plan  must  be  made  to  Commandant  (G-TPP)  by  1  May  of  each  year. 
Commandant  Instruction  M5230.8( series)  is  the  Coast  Guard  ADP  Plan. 

Funding  information  for  all  systems  and  proposals  is  included  in  the  ADP  Plan. 
Summary  budget  data  is  compiled  for  all  operating  agencies  by  the  Department  of 
Transportation  into  the  DOT  ADP  Plan,  which  satisfies  DOT'S  planning  requirements 
for  ADP  as  well  as  reporting  requirements  specified  by  the  Office  of  Management  and 
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Budget  (OMB).  OMB  takes  the  data  from  the  DOT  ADP  Plan  and  sets  an  ADP 
Obligation  Ceiling  for  the  Department  of  Transportation.  DOT,  in  turn,  sets  an  ADP 
Obligation  Ceiling  for  the  Coast  Guard,  which  in  turn  sets  unit  ceilings  for  units 
reporting  in  the  Coast  Guard  ADP  Plan.  Units  submitting  input  to  the  ADP  Plan 
must  identify  the  source  of  funds  for  their  projects.  RCP's  for  AC&I,  OE  and  RDT&E 
funds  are  submitted  by  operating  and  support  program  managers  for  larger  ADP 
systems. 

System  proposals  reported  in  the  ADP  Plan  are  not  necessarily  approved  simply 
by  their  appearance  in  the  plan.  Projects  with  estimated  life  cycle  costs  is  excess  of 
S 50, 000  require  the  approval  of  Commandant  (G-T).  In  cases  where  life  cycle  costs  are 
expected  to  exceed  the  Coast  Guard's  blanket  delegation  of  procurement  authority  of 
S50,000  for  ADP  resources,  DOT  approval  must  be  sought.  The  recommended  method 
to  request  approval  of  a  system  is  to  submit  a  request  for  advance  approval  with  the 
annual  ADP  Plan  submission.  The  advance  approval  request  should  appear  in  the 
ADP  Plan  one  year  before  approval  is  necessary  to  allow  for  DOT  review.  Systems 
not  using  the  advance  approval  process  should  expect  delays  in  receiving  DOT 
approval.  Those  systems  not  appearing  in  the  ADP  Plan  with  acquisition  life  cycle 
costs  in  excess  of  S50,000  will  require  DOT  approval,  but  will  only  be  considered  on  a 
case  by  case,  time  available  basis.  Consolidation  of  all  proposed  systems  and  requests 
for  approval  provides  the  reviewing  authorities  with  an  overall  picture  of  where  the 
Coast  Guard  is  going  with  ADP  and  information  systems. 

B.  MAJOR  SYSTEMS 

OMB  Circular  No.  A-109,  Major  System  Acquisition,  specifies  the  procedures  to 
be  followed  during  the  acquisition  process  of  systems  designated  as  major.  Agencies  of 
the  federal  government  are  mandated  to  implement  the  A-109  process  for  their  major 
acquisitions.  However,  each  agency  is  allowed  to  determine  the  criteria  of  systems  that 
do  or  do  not  qualify  as  major  systems.  Major  systems  acquisition  programs  are  those 
programs  that  (1)  are  directed  at,  and  are  critical  to,  fulfilling  a  Departmental  mission. 
(2)  entail  the  allocation  of  relatively  large  resources,  or  (3)  warrant  special  management 
attention  [Ref.  5:  p.  2].  The  Department  of  Transportation's  (DOT)  major  systems 
criteria  are: 

•  Total  system  acquisition  cost  exceeds  5150,000,000;  or 

•  Research  and  development  costs  in  excess  of  S25.000.000;  or 

•  DOT  secretarial  review  designates  the  system  as  a  major  system. 


Acquisition  costs  are  those  costs  incurred  over  the  life  of  the  system  starting  with  the 
concept  formulation  up  to  and  including  implementation.  Acquisition  costs  do  not 
include  system  maintenance  costs. 

Input  for  budget  planning  for  new  and  ongoing  acquisitions  which  meet  the 
above  dollar  criteria  for  major  systems  is  submitted  to  the  Department  of 
Transportation,  Assistant  Secretary  for  Budget  and  Programs  by  the  first  of  May  each 
year.  For  proposed  systems,  a  memorandum  on  the  major  systems  candidate, 
Appendix  B,  and  a  mission  need  statement  (MNS),  Appendix  C,  are  required  inputs. 
The  memorandum  on  the  major  systems  candidate  is  basically  a  one  page  condensation 
of  the  mission  need  statement.  However,  it  also  includes  a  recommendation  as  to 
whether  or  not  the  project  should  be  designated  a  major  system. 

The  major  systems  acquisition  process  is  broken  down  into  a  series  of  more 
manageable  subprocesses  separated  by  decision  points.  They  are  called  Key  Decisions 
in  the  Department  of  Transportation's  implementation  of  Circular  No.  A-109's 
procedures,  described  in  DOT  Orders  4200.14(series)  and  4200.9(series).  The  Deputy 
Secretary  of  Transportation  retains  the  approval  authority  at  each  Key  Decision  point 
unless  specifically  delegated.  Recommendations  at  each  Key  Decision  are  provided  to 
the  Deputy  Secretary  from  the  Transportation  Systems  Acquisition  Review  Council 
(TSARC).  The  membership  of  the  TSARC  is: 

•  Deputy  Secretary  (S-2),  chairman 

•  Assistant  Secretary  for  Policy  and  International  Affairs  (P-1) 

•  Assistant  Secretary  for  Budget  and  Programs  (B-l) 

•  Assistant  Secretary  for  Governmental  Affairs  (I- 1) 

•  Assistant  Secretary  for  Administration  (M-l) 

•  Assistant  Secretary  for  Public  Affairs  (A-l) 

•  General  Counsel  (C-l) 

•  Director,  Office  of  Installations  and  Logistics  (M-60),  TSARC  Executive 
Secretary. 

Missions  are  those  responsibilities  mandated  or  delegated  to  an  agency  for 
satisfying  a  national  need.  The  mission  need  statement  describes  a  mission  deficiency 
or  opportunity  to  more  effectively  or  efficiently  perform  mission  responsibilities.  It  is 
important  to  recognize  that  the  MNS  is  not  intended  to  propose  a  solution,  but  merely 
to  document  a  perceived  need.  Format  for  the  MNS  is  provided  in  Appendix  C. 


OMP  Circular  No.  A-109  requires  a  continuing  analysis  of  current  and  forecasted 
mission  capabilities,  technological  opportunities,  overall  priorities  and  resources 
that  are  involved.  When  the  analysis  identifies  a  deficiency  in  existing  agency 
capabilities  or  an  opportunity  to  establish  new  capabilities  in  response  to  a 
technologically  feasible  opportunity,  this  will  formally  be  set  forth  in  a  mission 
need  statement.  [Ref.  6:  p.  8] 

The  original  standard  terminal  acquisition  was  an  opportunity  for  the  Coast  Guard  to 
establish  new  capabilities  for  both  operations  and  support  because  of  a  relatively  new 
technology,  microcomputers.  It  was  so  new,  the  Coast  Guard  and  the  Department  of 
Transportation  were  not  quite  sure  how  to  proceed  with  the  acquisition. 

Budget  estimates  included  in  the  mission  need  statement  determine  how  DOT  will 
choose  to  manage  the  acquisition.  The  secretarial  review  process  will  be  discussed  in  a 
later  section. 

Approval  of  a  mission  need  statement  by  the  Deputy  Secretary  is  a  prerequisite 
to  proceed  further  with  the  project.  Following  approval  of  the  mission  need  statement 
(MNS)  a  project  officer  (PO)  should  be  designated  as  soon  as  possible.  The  project 
officer  should  draw  up  a  charter,  basically  a  contract  between  the  PO  and  his  her 
superiors  outlining  the  job  description,  responsibilities,  and  authority.  The  charter  is 
approved  by  the  Chief  of  Staff  (G-CCS).  The  project  officer  reports  directly  to  the 
program  director.  For  ADP  acquisitions  the  project  officer  reports  to  the  Chief,  Office 
of  Command,  Control  and  Communications  (G-T).  The  responsibilities  of  a  project 
officer  include  [Ref.  4:  p.  16-3]: 

•  Ensuring  the  project  is  responsive  to  mission  needs,  as  stated  in  the  mission 
needs  statement  (MNS) 

•  Develop  project  objectives 

•  Establishing  project  schedules 

•  Providing  necessary  budget  documentation 

•  Preparing  and  updating  the  acquisition  paper  (AP)  and  other  documentation, 
ana 

•  Executing  approved  AP  milestone  schedules. 

Depending  upon  the  size  of  the  project  the  project  officer's  job  may  become  very 
complex  and  demanding.  In  general  the  project  officer  should  be  chosen  based  upon 
background  and  experience  in  the  field.  OMB  Circular  No.  A-109  refers  to  the 
managers  of  major  acquisitions  as  program  managers.  The  A-109  program  manager  is 
not  to  be  confused  with  the  Coast  Guard's  program  manager.  A  program  manager  in 
the  Coast  Guard  refers  to  support  or  operating  program  managers  who  oversee  the 


various  Coast  Guard  missions  and  support  programs  for  those  missions.  A  project 
o fTicer  in  the  Coast  Guard  acquisition  process  is  the  equivalent  of  the  A- 109  program 
manager. 

Next,  the  acquisition  paper  (AP)  is  prepared.  The  acquisition  paper  is  the  key 
justification  and  documentation  of  a  system  as  it  progresses  through  the  acquisition 
process.  The  acquisition  paper  contains,  among  other  things,  the  acquisition  strategy 
and  estimated  costs,  a  projected  schedule  and  milestones,  notable  studies  such  as 
economic  analysis  and  feasibility  studies,  and  recommendations  to  proceed  through  the 
current  Key  Decision  point.  See  Appendix  A  for  the  format  of  an  AP.  The  Federal 

Acquisition  Regulations  require  that  an  acquisition  plan  be  prepared  early  in  the 

acquisition  process  to  promote  full  and  open  competition  [Ref.  7:  Sec.  1.7.103).  The 
acquisition  paper  satisfies  the  acquisition  plan  requirement. 

Key  Decision  1,  the  authorization  to  proceed  with  the  exploration  of  alternative 
system  design  concepts,  occurs  when  the  acquisition  paper  is  approved  for  the  first 

time  by  the  Deputy  Secretary.  This  is  the  nod  to  proceed  with  documenting  the 

functional  requirements  of  the  proposed  system.  Input  should  be  solicited  from  all 
possible  beneficiaries  of  the  system. 

Advancement  to  the  competitive  test  and  demonstration  phase  of  the  acquisition 
occurs  upon  the  approval  of  the  updated  acquisition  paper.  Key  Decision  2.  The 
updated  AP  should  contain  updates  on  the  system  acquisition  costs,  updated  goals  and 
schedule,  significant  changes  and  status  reports  on  program  activities.  In  th>  phase, 
contractor  proposed  systems,  based  upon  the  functional  and  technical  specification 
requirements,  are  evaluated  on  paper  for  economic  comparison  and  technical 
compliance.  An  operational  capabilities  demonstration  (OCD)  is  also  required  to 
demonstrate  their  compliance. 

Upon  completion  of  the  test  and  demonstration  phase  the  AP  is  once  again 
updated.  The  test  results  and  cost  evaluations  from  this  phase  will  be  included  in  the 
AP  update.  Again  status  reports  and  other  updates  support  the  recommendation  to 
proceed  in  the  AP.  Key  Decision  3.  commitment  of  a  system  to  full  scale  development 
and  limited  production,  occurs  upon  approval  of  the  AP.  Selection  of  the  system  that 
most  economically  and  efficiently  meets  the  needs  and  specifications  happens  during 
this  phase. 

Key  Decision  4,  commitment  of  a  system  to  full  production,  occurs  upon  the 
approval  of  the  updated  AP.  At  this  point  the  selected  system  is  procured  and 


distributed  to  field  units  as  necessary  to  meet  the  documented  needs  of  the  operating 
agency-. 

As  the  acquisition  process  progresses,  quarterly  reports  must  be  submitted  to  the 
TSARC  for  review.  The  quarterly  status  reports  shall  assess  cost,  schedule  and 
technical  performance  experience  against  predictions  [Ref.  5:  p.  9],  and  include 
observations  and  recommendations  as  to  how  the  variance  may  affect  the  life  cycle 
cost.  Appendices  E  and  F  provide  the  sample  format  and  status  codes  required  for  the 
quarterly  status  reports. 

C.  SECRETARIAL  REVIEW 

The  secretarial  review  process  applies  to  proposed  systems  that  fall  below  the 
dollar  requirements  for  major  systems,  but  have:  (1)  total  acquisition  costs  greater  than 
S20 ,000,000;  or  (2)  anticipated  3  year  research  and  development  costs  that  exceed 
S5.000.000  [Ref.  8:  p.  1], 

A  one  page  memorandum  similar  to  the  memorandum  for  major  systems 
candidates  is  submitted  by  1  May  of  each  year  to  the  Assistant  Secretary  for  Budget 
and  Programs.  This  memorandum  contains  a  brief  recommendation  and  reasoning 
concerning  the  applicability  of  TSARC  review  and  involvement  in  the  acquisition.  The 
Assistant  Secretary  for  Budget  and  Programs  prepares  recommendations,  based,  on 
input  from  other  secretarial  offices,  and  submits  them  to  the  Deputy  Secretary.  As 
soon  as  possible  the  Deputy  Secretary  makes  a  determination  on  each  system  and 
places  them  in  one  of  the  following  categories: 

•  MSA  -  Major  Systems  Acquisition 

•  TPL  -  TSARC  Program  List 

•  NBR  -  Normal  Budget  Review. 

A  major  systems  designation  of  one  of  these  lower  cost  acquisitions  signifies  the 
importance  of  or  Secretarial  interest  in  the  particular  project.  The  procedures  discussed 
earlier  for  major  systems  acquisition  must  be  followed. 

Systems  included  in  the  TSARC  program  list  basically  follow  the  same  process  as 
major  systems.  In  fact  it  is  a  scaled  version  of  the  A- 109  process  with  the  Key 
Decisions  delegated  to  lower  organizational  levels.  An  acquisition  paper  must  be 
submitted  and  approved  by  the  Deputy  Secretary,  quarterly  status  reports  are  also 
required.  However,  the  decision  authority  at  the  Key  Decision  points  is  delegated  to 
the  head  of  the  responsible  DOT  agency,  unless  specifically  withheld  by  the  Deputy 


Secretary  upon  approval  of  the  AP.  The  Commandant  is  the  Decision  Authority  for 
the  Coast  Guard.  The  Deputy  Secretary  should  receive  an  updated  acquisition  paper 
for  review  and  approval  only  if  the  acquisition  exceeds  any  limitations  imposed  by  him 
or  if  it  deviates  significantly  from  cost  and/or  schedule  baselines.  Under  these 
conditions  the  Deputy  Secretary's  acquisition  approval  is  necessary  before  the 
acquisition  proceeds  further. 

Programs  not  specifically  categorized  as  MSA  or  TPL  fall  into  the  normal  budget 
review  category.  These  systems  will  be  considered  in  the  budget  review  process  for 
funding  and  approval.  It  should  be  noted  that  approval  of  an  acquisition  paper  and 
designation  of  an  acquisition  as  a  major  system  or  TSARC  Program  List  does  not 
guarantee  funding  in  the  budget  process.  The  approved  acquisition  paper  is  used  as 
background  support  information  and  justification  of  a  project  in  the  RCP  submitted 
during  the  budget  development  process. 

D.  PROCUREMENT  AUTHORITY  FOR  ADP  RESOURCES 

The  General  Services  Administration  (GSA)  has  exclusive  procurement  authority 
for  the  federal  government  for  ADP  resources  under  40  USC  759  [Ref.  9:  Sec. 
201-23.100].  Procurement  authority  may  be  delegated  to  agencies  of  the  federal 
government  by  GSA.  Delegation  of  procurement  authority  (DPA)  allows  agencies  to 
proceed  with  a  particular  ADP  acquisition  without  further  involvement  from  GSA.  A 
blanket  delegation  of  procurement  authority  has  been  granted  to  all  agencies,  which 
includes  the  Department  of  Transportation.  For  procurements  made  through 
competitive  solicitation  procedures1  the  following  DPA  is  granted  to  executive 
agencies: 

•  ADP  equipment  purchases  not  to  exceed  S2, 500, 000 

•  ADP  equipment  rental  charges  including  maintenance  not  to  exceed  S  1,000,000 
annually 

•  Software  acquisition  not  to  exceed  51,000,000 

•  Maintenance  services  not  to  exceed  SI, 000, 000  annually. 

Agency  DPA's  can  be  further  delegated  to  its  organizational  components.  The 
Department  of  Transportation's  delegation  of  procurement  authority  to  the  Coast 
Guard  is  S50.000  for  ADP  equipment  which  does  not  appear  in  the  DOT  ADP  Plan, 
and  a  maximum  of  5300,000  for  approved  systems  which  appear  in  the  DOT  ADP  Plan 


lTo  satisfy  full  and  open  competition  required  bv  the  Competition  in  Contractine 
Act  of  1984. 


[Ref.  10:  p.  9].  The  DOT  ADP  Plan  is  a  planning  and  budgeting  document  for  ADP 
resources  in  the  Department  of  Transportation.  It  was  discussed  in  an  earlier  section 
of  this  thesis. 

Acquisitions  of  ADP  resources  by  the  Coast  Guard  which  exceed  its  procurement 
authority  delegated  by  the  Department  of  Transportation  must  be  presented  to  the 
Assistant  Secretary  for  Administration  (M-l)  for  approval.  For  ADP  systems  with 
acquisition  costs  which  are  expected  to  exceed  DOT'S  blanket  DPA,  an  agency 
procurement  request  (APR)  must  be  submitted  to  the  General  Services  Administration 
through  the  Department  of  Transportation.  Coordination  with  GSA  prior  to 
submitting  the  APR  is  encouraged.  Identification  of  problem  areas  early  in  the  process 
may  eliminate  possible  delays  in  approving  the  APR  and  the  granting  of  the  delegation 
of  procurement  authority  for  that  particular  acquisition  [Ref.  9:  Sec.  201-23.106].  DOT 
recommends  use  of  the  alternative  APR  submission,  the  description  and  format  of 
which  is  shown  in  Appendix  G.  Two  copies  of  the  APR  should  be  submitted  to  GSA. 
GSA  will  review  the  request  and  take  action  within  20  days  of  receipt  of  the  necessary 
information.  After  20  days,  plus  5  days  for  mail  delay,  if  no  w'ord  has  been  received 
from  GSA  the  agency  may  act  as  if  the  DPA  has  been  granted  and  proceed  with  the 
acquisition  process.  The  20  day  deadline  is  set  by  GSA  when  it  responds  in  wiiting 
stating  that  the  necessary  information  has  been  received.  The  commencement  oate  of 
the  20  day  review  period  will  be  in  the  notification.  No  solicitation  or  contracting 
activity  may  begin  until  the  DPA  has  been  granted. 

E.  THE  MODEL 

Now  that  some  background  has  been  provided  for  some  of  the  most  important 
mandated  elements  concerning  acquisition  of  ADP  resources,  a  model  will  be 
developed  that  incorporates  everything  up  to  this  point. 

The  Key  Decision  points  discussed  in  the  Major  Systems  Acquisition  section 
remain  the  important  milestones  in  any  acquisition  process  which  meet  or  exceed  the 
criteria  for  secretarial  review.  However,  for  the  purpose  of  an  acquisition  of  off-the- 
shelf  ADP  resources.  Key  Decision  2  and  3  are  usually  combined  into  one  decision 
[Ref.  6:  p.  24]  to  streamline  the  process.  It  is  sometimes  referred  to  as  customizing  the 
acquisition.  The  proposed  ADP  acquisition  model  is  based  on  redefining  the  phases 
between  each  Key  Decision  w'ith  a  single  broad  term  that  describes  the  activities  that 
occur  during  that  phase.  Figure  4.1  illustrates  the  basic  model. 
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Figure  4.1  Comparison  of  the  Proposed  Model  with  the  A- 109  Process. 


Each  phase  in  the  life  cycle  should  be  concrete  and  identifiable.  Separation 
milestones  between  phases  are  major  decision  points.  Transition  is  accomplished  by 
satisfactory  completion  of  predetermined  milestones.  This  does  not  mean  that 
requirements  and  determinations  from  an  earlier  phase  cannot  be  reconsidered  and 
possibly  modified  later.  Problems  are  cheaper  and  easier  to  work  out  in  the  earlier 
phases  than  in  the  later  ones.  For  example,  requirements  considerations  should  be 
handled  early  in  the  process  while  the  analysis  oriented  personnel  are  working  on  the 
project.  A  contracting  officer  should  not  be  left  to  make  determinations  on  the 
functionality  of  hardware  merely  because  a  portion  of  the  requirements  analysis  was 
overlooked.  On  the  other  hand,  deleting  an  unnecessary  requirement  or  adding  a  new 
critical  function  should  not  be  ignored  simply  because  that  stage  of  the  project  has 
passed.  A  system  that  is  obsolete  or  useless  when  it  is  finally  acquired  has  failed 
somewhere  along  the  acquisition  process. 

It  is  very'  Important  not  to  proceed  ahead  in  the  project  cycle  before  the 
authorization  to  proceed  has  been  granted.  This  avoids  wasted  time,  effort  and  money. 
All  the  necessary  details  possible  should  be  considered  and  planned  before  proceeding. 

Documentation  is  also  necessary.  It  may  be  used  to  prove  regulatory 
compliance.  More  importantly,  the  thought  process  and  reasoning  whith  drove  the 
project  may  prove  invaluable  at  a  later  point  in  time. 

1.  The  Planning  Phase 

The  planning  phase  of  this  acquisition  model  begins  with  the  conception  of  an 
idea  to  develop  or  acquire  an  ADP  system.  For  the  purposes  of  this  thesis, 
consideration  will  be  limited  to  multipurpose  hardware  and  software.  The  development 
or  replacement  of  an  ADP  system  may  be  considered  for  many  reasons.  Among  the 
possibilities;  obsolescence  of  an  existing  system,  new  requirements  mandated  by 
mission  or  law,  new  technological  opportunity,  or  simply,  a  suggestion  to  improve 
performance  and  capabilities  in  any  of  the  many  things  the  Coast  Guard  does. 
Regardless  of  the  origination  of  the  idea,  all  systems  must  proceed  through  the  same 
planning  steps  to  be  able  to  proceed  on  to  the  approval  phase. 

First  a  preliminary  analysis  or  feasibility  study  should  be  performed.  The 
feasibility  study  looks  into  the  technical,  economic,  operational  and  political 
implications  and  restrictions  associated  with  the  proposed  system.  After  considering 
these  factors,  the  formal  objectives  and  a  sense  of  the  scope  of  the  project  are  known. 
If  the  proposed  system  is  technically,  economically,  operationally  and  politically 


feasible,  a  decision  can  be  made  to  proceed  with  the  system  planning  based  upon  a 
preliminary  cost  benefit  analysis  done  by  comparing  the  objectives  against  against  a 
rough  cost  from  the  feasibility  study. 

The  ADP  Plan,  as  mentioned  earlier,  is  a  planning  tool  used  by  the  Coast 
Guard  and  the  Department  of  Transportation  to  budget  for  ADP  equipment  and 
services  over  a  5  year  time  frame.  Submission  to  the  ADP  Plan  should  occur  as  soon 
as  possible  once  a  determination  is  made  that  the  proposed  system  merits  further 
consideration  and  could  possibly  be  acquired. 

Defining  system's  requirements  follows  the  feasibility  study.  When  the  scope 
of  the  project  is  understood,  the  determination  of  need  and  requirements  analysis 
addresses  considerations  such  as  the  type  of  information  to  be  processed,  security  and 
privacy  concerns,  volume  of  data,  probable  benefits,  site  preparation  and  risks 
[Ref.  9:  Sec.  201-30.007].  See  Appendix  H  for  minimum  requirements  analysis 
considerations. 

For  existing  systems,  conversion  costs  must  be  considered  to  insure  that  ADP 
needs  are  met  at  the  lowest  overall  cost.  Conversion  costs  include  software  conversion, 
site  preparation  and  modifications,  and  travel  and  training  expenses  [Ref.  9:  Sec. 
201-30.012-2].  As  a  rule  they  are  expenses  that  would  not  normally  be  incurred 
without  transition  to  a  different  system.  Comprehensive  software  conversion  studies 
are  required  in  the  following  instances: 

•  The  estimated  purchase  price  or  life  cycle  cost  of  the  system  is  expected  to 
exceed  S2.o  million;  or 

•  The  cost,  .of  the  conversion  is  to  be  used  as  primary  justification  for  a 
compatibility  limited  requirement. 

If  it  becomes  necessary  or  desirable  to  add  to  or  replace  a  system  with  equipment 
which  must  be  compatible  with  the  existing  system,  a  statement  justifying  the 
compatibility  limited  requirement  must  be  prepared.  The  justification  must  include 
[Ref.  9:  Sec.  201-30.009-3]: 

•  Software  conversion  study 

•  Mission  essential  data  processing  requirements 

•  Analysis  which  shows  the  proposed  method  is  lowest  overall  cost  over  the 
system  life. 

Appendix  I  contains  the  considerations  for  determining  whether  a  compatibility  limited 
requirement  is  justified. 


Completion  of  the  various  studies  described  above  brings  the  planning  phase 
to  a  close.  The  studies  are  prerequisites  and  necessary  enclosures  for  documents  to  be 
submitted  during  the  approval  phase. 

2.  The  Approval  Phase 

All  the  planning  in  the  world  can  be  done  for  a  project,  but  that  project  will 
never  progress  until  those  in  the  position  of  approval  grant  their  authorization  to 
proceed  with  the  project.  Three  major  objectives  make  up  the  approval  phase. 

First,  advance  approval  must  be  sought  through  the  ADP  Plan.  From  the 
reported  information,  an  obligation  ceiling  for  ADP  is  passed  down  from  OMB 
through  DOT,  eventually  down  to  the  level  seeking  authorization  for  its  project. 
Project  approval  for  the  ADP  Plan  should  be  requested  one  year  prior  to  its  desired 
approval.  The  approval  request  is  then  published  in  the  ADP  Plan. 

The  second  major  objective  is  to  gain  approval  of  the  mission  need  statement, 
and  if  one  is  required,  the  initial  acquisition  paper.  These  two  documents  taken 
together,  provide  a  formal  statement  of  the  project,  an  analysis  of  the  costs  and 
benefits,  scheduled  milestones,  and  other  project  management  considerations.  Refer  to 
Appendices  A  and  C  for  the  contents  of  the  acquisition  paper  and  mission  needs 
statement,  respectively.  The  actual  approval  process  for  the  MNS  and  AP  is  covered 
in  Section  B  of  this  chapter,  Major  Systems. 

Finally,  procurement  authority  for  ADP  equipment  and  services  rests,  by  law, 
with  the  General  Services  Administration.  Blanket  procurement  authority  is  delegated 
to  agencies,  riot  to  exceed  specified  dollar  thresholds.  In  cases  where  the  projected 
costs  will  exceed  the  delegated  procurement  authority,  an  agency  procurement  request 
must  be  submitted  to  GSA  through  the  Coast  Guard  chain  of  command  and  then 
through  DOT.  DOT  review  is  contingent  upon  the  project's  appearance  in  the  ADP 
Plan.  GSA  requires  the  MNS,  a  conversion  study  and,  if  appropriate,  a  determination 
of  compatibility  requirement.  GSA  approval  of  the  APR  results  in  the  granting  of  a 
delegation  of  procurement  authority.  The  DPA  may  contain  restrictions  and  or 
specific  reporting  requirements  which  apply  to  the  particular  acquisition.  Section  D  of 
this  chapter.  Procurement  Authority  for  ADP  Resources,  describes  the  agency 
procurement  request  process  in  more  detail. 

Completion  of  the  approval  phase  corresponds  to  Key  Decision  l  of  DOT  s 
implementation  of  the  A- 109  process.  Key  Decision  1  is  the  authorization  to  proceed 
with  the  exploration  of  alternative  system  design  concepts.  Key  Decision  l  actually 


occurs  earlier  in  the  acquisition  process  than  the  completion  of  the  approval  phase. 
Approval  of  the  initial  acquisition  paper  is  Key  Decision  1.  The  approval  phase  goes 
one  step  further  by  obtaining  approval  of  the  agency  procurement  request,  which 
contains  the  approved  mission  need  statement  and  other  pertinent  information  from 
the  initial  acquisition  paper. 

3.  The  Solicitation  Phase 

The  purpose  of  the  solicitation  phase  is  to  prepare  a  request  for  proposal 


(RFP)  to  be  made  available  for  all  parties  interested  in  bidding  on  the  proposed  system 
or  service.  The  conclusion  of  this  phase  occurs  when  the  deadline  for  bids  passes  and 
the  evaluation  of  proposals  commences. 

A  selection  plan  (SP)  is  prepared  by  the  contracting  ofTicer  in  coordination 
with  the  program  oflice  responsible  for  the  project.  Appendix  J  contains  the  details  of 
a  selection  plan.  Approval  of  the  selection  plan  is  required  prior  to  issuing  the  RFP. 

The  Source  Selection  Official  (SSO)  approves  the  SP.  In  the  case  of  large 
contracts,  greater  than  S2  million,  the  Assistant  Secretary  for  Administration  is  the 
SSO,  unless  he:  she  chooses  to  delegate  the  authority.  Submission  of  the  selection  plan 
to  the  SSO  should  be  withheld  until  an  acquisition  paper  has  been  approved  if  the 
procurement  falls  under  the  review  of  DOT  Order  4200. 9 A,  Acquisition  Review  and 
Approval,  or  DOT  Order  4200. 14B,  Major  Systems  Acquisition  Review  and  Approval 
[Ref.  11:  p.  1-1]. 

Members  of  the  Source  Evaluation  Board  (SEB)  are  specifically  designated  in 
thie  approved  selection  plan.  Source  Evaluation  Board  duties  take  priority  over  normal 
duty  assignments  [Ref.  11:  p.  III-3].  The  SEB  is  made  up  of  a  maximum  of  7  members. 
Evaluation  teams  are  formed  from  the  members  of  the  SEB.  Advisors  and  experts 
outside  the  membership  of  the  SEB  may  be  brought  in  to  assist  the  teams.  However, 
acquisition  related  information  available  to  those  personnel  should  be  limited  to  that 
which  is  necessary  for  satisfactory  completion  of  their  tasks.  Source  Evaluation  Board 
recommendations  are  submitted  to  the  SSO  to  provide  assistance  in  and  a  basis  for  the 
selection,  award  decisions  made  by  the  SSO. 

Work  on  the  RFP  may  begin  sometime  before  approval  of  the  selection  plan. 
The  request  for  proposals  is  prepared  by  the  contracting  officer.  A  draft  RFP  may  be 
released  to  industry  for  questions  and  comments.  Questions  and  comments  from 
potential  bidders  clarify  ambiguities  in  the  RFP.  More  responsive,  higher  quality  bids 
result  from  this  process.  The  final  RFP  is  typically  available  for  review  by  the  Source 
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Evaluation  Board  at  one  of  its  early  meetings.  The  SSO  is  briefed  on  the  RFP  after  it 
is  reviewed  by  the  SEB. 

Development  of  a  source  list,  and  evaluation  criteria  must  be  completed  before 
the  RFP  can  be  considered  for  release.  The  source  list  contains  recommended  sources, 
but  does  not  implicitly  exclude  any  source  not  on  the  list.  The  evaluation  criteria  and 
weighted  scoring  procedures  must  be  completed  prior  to  issuing  the  RFP  to  insure 
impartial  evaluations,  and  to  let  the  bidders  know  what  is  considered  important  in  their 
proposals.  RFP  information  is  contained  in  Appendix  K. 

Proposed  contract  actions  greater  than  525,000  must  be  synopsized  in  the 
Commerce  Business  Daily  (CBD)  [Ref.  7:  Part  1.5].  The  notice  must  appear  in  the 
CBD  at  least  15  days  before  release  of  the  RFP.  This  gives  interested  vendors,  who  do 
not  appear  on  the  source  list,  an  opportunity  to  request  a  solicitation.  At  a 
predetermined  date  vendors,  both  on  the  source  list  or  requesting  solicitations,  are  sent 
a  copy  of  the  RFP.  Deadlines  for  bid/proposal  submissions  are  set.  The  deadline  may 
not  be  less  than  30  days  from  the  release  of  the  solicitation. 

4.  The  Evaluation  Phase 

The  evaluation  phase  begins  after  the  solicitation  deadline  has  expired  and 
proposals  have  been  received.  Proposals  arriving  after  the  announced  deadline  are 
typically  not  evaluated.  The  SEB  is  convened  to  evaluate  the  proposals.  First,  a 
preliminary  review  is  made  of  the  proposals.  Specifically,  the  SEB  looks  for  proposals 
that  may  be  eliminated  at  this  early  stage,  before  detailed  analysis  is  performed. 
Proposals  that  are  deficient  in  one  or  more  areas  or  show  that  the  offerer  did  not 
understand  the  solicitation  are  eliminated.  Eliminated  offerers  are  notified  as  soon  as 
possible  concerning  the  reasons  for  elimination,  and  to  inform  them  that  resubmission 
of  their  proposals  will  not  be  considered. 

Next,  the  evaluation  team  begins  analysis  of  the  proposals.  Ambiguities  in 
any  proposal  are  directed  back  to  the  SEB.  The  SEB  forwards  them  to  the  contracting 
officer,  who  contacts  the  offerer  for  clarification.  After  ambiguities  are  worked  out,  the 
teams  evaluate  the  proposals  based  on  the  approved  evaluation  plan  and  weighting 
criteria. 

To  evaluate  the  operation  and  performance  of  proposed  systems,  the  use  of 
operational  capability  demonstrations  (OCD)  and  performance  validation  techniques, 
such  as  benchmarking,  are  required  in  contracting  for  ADP  equipment  systems, 
components  and  software  [Ref.  9:  Sec.  201-24.215].  The  usefulness  of  the  OCD 


depends  on  the  quality  and  completeness  of  the  systems  requirements  in  the  RFP.  One 
of  the  teams  from  the  SEB  will  observe  and  score  the  OCD's.  After  evaluations  are 
complete,  each  team  provides  a  written  report  to  the  SEB  describing  the  strengths  and 
weaknesses  of  the  various  proposals. 

A  preliminary  determination  of  competitive  range  is  made  by  the  SEB.  This 
determination  eliminates  all  proposals  that  do  not  have  a  reasonable  chance  of  being 
selected  for  final  award.  Those  offerers  eliminated  at  this  point  are  promptly  notified 
of  the  reasons  for  their  elimination  and  that  resubmission  of  their  proposals  will  not  be 
considered. 

Offerers  who  remain  are  given  the  opportunity  to  improve  their  proposals. 
Weaknesses  and/or  deficiencies  are  pointed  out  to  them.  No  recommendations  are 
made  concerning  how  to  improve  or  correct  the  proposals.  Major  rewrites  of 
submitted  proposals  are  not  allowed  at  this  stage  and  should  not  be  considered. 
Revised  proposals  are  rescored  by  the  teams.  Final  scores  from  this  stage  are 
presented  to  the  SSO  in  a  written  report. 

Completion  of  the  evaluation  phase  corresponds  to  Key  Decision  3.  Recall 
that'  Key  Decisions  2  and  3  are  typically  combined  for  acquisition  of  off-the-shelf  ADP 
resources.  Referring  back  to  Figure  4.1,  Key  Decision  3  marks  the  end  of  Evaluation 
of  Alternative  System  Design  Concepts,  and  Test  and  Demonstration  phases  of  the 
DOT  A- 109  implementation.  At  this  point  the  acquisition  paper  should  be  completely 
updated  for  review'  by  the  approval  authority  to  proceed  into  the  next  phase. 

5.  The  Selection  Phase 

Based  upon  the  Source  Evaluation  Board's  report,  the  SSO  returns  a 
determination  to  the  SEB  of  contractors  within  the  competitive  range  for  contract 
negotiation.  This  is  the  beginning  of  the  selection  phase. 

Prior  to  negotiations  with  contractors  the  SEB  advises  the  negotiating  team  of 
factors  it  considers  important.  The  SEB  also  reviews  the  negotiating  team's  position 
and  objectives  before  commencement  of  negotiations. 

All  offerers  are  permitted  adequate  time  to  alter  their  proposals  based  on 
topics  discussed  in  negotiations.  Best  and  final  proposals  should  be  submitted  by  the 
date  specified.  The  SEB  reevaluates  the  best  and  finals  but  does  not  necessarily  have 
to  completely  rescore  them.  The  board  prepares  a  written  report  to  the  Source 
Selection  Official.  The  SSO  then  selects  the  offerer  who  will  be  awarded  the  contract 
and  documents  his/her  decision. 
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The  selection  phase  is  not  complete  until  the  unsuccessful  bidders  have  been 
debriefed  concerning  their  elimination  from  consideration.  The  contracting  ofTicer 
along  with  members  of  the  Source  Evaluation  Board  discuss  the  strengths  and 
weaknesses  of  their  proposals,  individually.  No  comparisons  are  made.  Only 
information  pertaining  to  the  particular  proposal  is  discussed.  Debriefing  is  done  to 
acknowledge  the  efforts  made  by  bidders.  More  importantly,  it  is  used  in  hopes  of 
receiving  higher  quality  bids  for  future  acquisitions. 

Completing  the  selection  phase  corresponds  to  Key  Decision  4,  Commitment 
of  a  system  to  full  production.  Although  full  production  may  not  be  an  appropriate 
term  for  off-the-shelf  ADP  equipment  and  services,  commitment  to  a  system  very 
accurately  describes  the  Key  Decision. 

6.  The  Implementation  Phase 

The  implementation  phase  commences  at  the  conclusion  of  the  selection 
phase.  This  phase  covers  the  activities  associated  with  establishing  the  ADP  capability 
within  the  Coast  Guard.  Justification  of  the  individual  need  for  resources  should  be 
submitted  by  the  requesting  activity  to  the  appropriate  approval  authority.  For 
example,  for  Coast  Guard  wide  applications  the  approval  authority  would  be  the 
responsible  program  manager.  Funding  sources  should  also  be  included  with  the 
justification.  Hardware  configurations  and  software  requirements  should  be  approved 
in  coordination  with  a  central  technical  office  to  insure  system  feasibility  and 
compatibility  with  Coast  Guard  standards. 

7.  Iterative  System  Evaluation  Cycle 

A  periodic  system  evaluation  is  one  of  the  most  important  life  cycle  events,  yet 
it  is  easily  forgotten  once  the  effort  of  acquiring  a  system  is  finished  and  the  excitement 
has  faded.  The  people  involved  with  the  acquisition  typically  go  away  and  leave  the 
system  to  the  users. 

Several  publications  address  the  need  for  this  evaluation.  The  Federal 
Information  Resources  Management  Regulations  call  it  an  audit  of  installed  systems; 
DOT  Order  1370.9  refers  to  it  as  a  post-installation  audit;  and  the  Department  of 
Defense  has  a  cyclic  life  cycle  phase  for  ADP  systems,  called  a  systems  effectiveness 
review. 

A  thorough  review  of  anv  svstem  is  needed  after  it  has  achieved  operational 
status.  The  primarv  objective  is  to  determine  if  the  svstem  has  achieved  the  cost 
and  benefit  goals  which  formed  the  basis  for  the  decision  to  proceed  with  the 
system.  Where  their  goals  were  not  met.  a  new  decision  is  required  -  on  the 


basts  of  the  achieved  benefits  andthe  continuing  cost  to  operate  and  maintain 
the  system  —  as  to  whether  the  effort  should  be  continued  of  abandoned.  The 
post-installation  audit  also  provides  an  excellent  method  of  evaluating  and 
improving  the  planning  and  development  process.  Post-installation  audits  must 
be^lanned^to  check  accuracy,  quality,  and  completeness  of  the  system. 

The  life  cycle  of  an  ADP  system  begins  when  planning  is  started  and 
continues  until  disposal  of  the  system.  Studies,  evaluations  and  other  documentation 
are  required  during  the  acquisition  portion  of  the  life  cycle.  The  historically  and 
hopefully  longest  life  cycle  phase  is  the  deployment  and  operation  phase.  An 
adequately  planned  system  should  satisfy  its  requirements  for  a  sufficiently  long  period 
of  time  to  justify  itself  and  then  some.  It  does  not  make  sense  to  quit  managing  and 
documenting  a  system  after  the  acquisition  has  been  completed.  The  majority  of  the 
system's  life  cycle  remains  after  the  acquisition  is  finished. 

The  iterative  system  evaluation  cycle  at  the  end  of  one  system's  life  cycle  may 
coincide  with  the  planning  phase  for  the  system  that  will  eventually  replace  it. 


V.  THE  ORIGINAL  STANDARD  TERMINAL  ACQUISITION 
A.  THE  ACQUISITION 

The  Coast  Guard  Standard  Terminal  is  an  acquisition  that  has  affected  the  Coast 
Guard  in  virtually  every  activity  and  mission  it  performs.  Standard  terminal  systems 
maintain  pay  data  (JUMPS),  marine  safety  information  (MSIS)  and  many  other 
applications  including  unique  programs  written  by  local  programmers  for  a  particular 
unit.  Standard  terminals  are  found  everywhere  in  the  Coast  Guard,  from  headquarters 
offices,  to  research  and  development  facilities,  to  ships  on  patrol.  This  chapter 
contains  a  brief  acquisition  history  of  the  Coast  Guard  Standard  Terminal.  The 
process  used  to  acquire  this  resource  will  be  presented  using  the  acquisition  model 
described  in  the  previous  chapter. 

1.  The  Planning  Phase 

Development  of  several  major  applications  was  under  consideration  during  the 
late  1970's.  Requirements  for  the  standard  terminal  were  based  on  the  requirements 
for  those  applications.  As  the  planning  progressed  the  requirements  matured.  What 
originally  started  out  as  a  dumb  terminal  grew  into  a  powerful  microcomputer  with 
telecommunications  features  and  the  capability  to  be  configured  in  a  cluster.2 
Commandant  Note  5233,  dated  11  June  1979,  solicited  input  from  the  Coast  Guard  to 
help  determine  what  capabilities  were  necessary  and  desireable.  The  request  for  input 
from  the  whole  Coast  Guard  got  everyone  involved  in  the  requirements  analysis. 
However,  it  seems  the  requirements  for  the  system  had  pretty  much  already  been 
determined  by  the  major  applications  needs.  The  Commandant  Note  asked  for  input 
on  such  things  as  keyboard  layout  and  other  terminal  features  which  would  not 
severely  impact  the  proposed  system  as  it  stood  at  that  time.  The  survey  gathered 
input  on  the  degree  to  which  the  proposed  standard  terminal  characteristics  were 
desired  and/or  necessary. 

Soon  after  the  Coast  Guard  decided  to  proceed  with  the  acquisition  of  a 
standard  terminal,  lead  members  of  the  project  began  selling  the  concept  and  benefits 
to  high  level  Coast  Guard  and  Department  of  Transportation  officials.  Because  this 
was  the  first  attempt  at  a  major  standardization  project  which  would  also  put  high 

2Local  Area  Network  (LAN) 


computer  capabilities  at  all  levels  of  the  Coast  Guard,  the  project  was  viewed  as  more 
political  than  anything  else.  High  level  briefings  were  used  to  get  the  support  of  those 
who  could  do  the  most  to  keep  the  momentum  of  the  project  going.  They  were  also 
used  to  help  prevent  the  shift  of  inertia  against  the  project.  In  addition  to  the 
applications  envisioned  at  that  time,  the  standard  terminal  was  presented  as  a 
capability  that  would  be  used  by  the  Coast  Guard  in  more  ways  than  could  be 
conceived  of  then.  Because  of  the  relatively  new  technology  concerned,  many  project 
managers  had  difficulty  grasping  the  potential  benefits  it  would  provide  to  their 
programs.  Budgets  and  specific  requirements  were  avoided  until  the  concept  was  sold. 
Later,  technology  reports  in  computer  publications  such  as  BYTE  and  ACM  would 
help  provide  the  acquisition  team  with  some  of  the  required  and  optional  features  in 
the  standard  terminal  specifications. 

The  standard  terminal  concept  was  submitted  to  the  Coast  Guard  ADP  Plan. 
A  description  of  the  applications  to  be  satisfied  and  the  Coast  Guard  ADP 
requirements,  both  current  and  future,  were  identified  as  goals  to  be  achieved  by 
implementation  of  the  standard  terminal. 

The  Coast  Guard  established  a  policy  to  place  ADP  costs  with  the  people 
using  the  capability.  Users  pay  for  what  they  need  and  use.  Consequently,  no 
standard  terminal  RCP  was  approved  to  pay  for  the  whole  project.  Rather,  individual 
program  managers  were  left  to  determine  the  standard  terminal  requirements  for  their 
programs  and  submit  budget  requests  for  those  needs. 

2.  The  Approval  Phase 

Because  the  estimated  cost  of  the  acquisition  exceeded  the  Coast  Guard's  and 
DOT'S  blanket  procurement  authority,  an  agency  procurement  request  was  submitted 
to  GSA.  The  APR  submitted  on  20  August  1979  estimated  the  terminal  acquisition 
costs  at  approximately  S6  million  over  a  5  year  contract  life.  Review  by  the  General 
Services  Administration  took  about  3  months.  The  delegation  of  procurement 
authority  was  granted  by  the  Assistant  Commissioner  for  Agency  Services  and 
Procurement  in  a  letter  dated  14  November  1979. 

The  standard  terminal  appeared  in  the  first  Coast  Guard  ADP  Plan 
promulgated  on  11  June  1979.  Although  no  specific  mention  of  approval  is  found  in 
the  first  ADP  Plan,  conceptual  approval  must  have  been  granted  by  this  point  in  time 
by  the  Coast  Guard  and  the  Department  of  Transportation  because  the  project 
continued. 
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Figure  5.1  depicts  the  activities  which  occured  during  the  planning  and 
approval  phases  of  the  standard  terminal  acquisition. 

By  April  1980  the  acquisition  had  gained  two  of  the  three  approval  objectives 
mentioned  in  the  model;  the  delegation  of  procurement  authority  had  been  granted, 
and  the  ADP  Plan  submission  was  approved.  The  third  objective  in  the  model  is 
approval  of  the  acquisition  paper..  Research  through  the  remains  of  the  acquisition  file 
turned  up  no  sign  of  an  acquisition  plan.  Acquisition  schedule  goals  and  milestones 
appear  on  several  documents.  However,  the  fact  that  no  acquisition  plan  exists  (or  can 
be  found)  severely  impairs  the  depth  of  review  possible.  Referring  back  to  the 
secretarial  review  process,  this  acquisition's  original  estimated  cost  of  S6  million  did  not 
meet  any  of  the  criteria  for  secretarial  review.  Therefore,  no  acquisition  paper  was 
required.  The  acquisition  team  realized  the  A- 109  process  would  apply  to  the  standard 
terminal  both  in  concept  and  cost.  Cost  estimates  were  deliberately  kept  low  to  keep 
the  project  from  being  administratively  delayed  in  the  A- 109  process.3 

Having  gained  what  approval  was  necessary  the  acquisition  process  moved 
into  the  solicitation  phase.  , 

3.  The  Solicitation  Phase 

According  to  my  model  the  solicitation  phase  begins  upon  the  approval  of  the 
selection  plan.  A  memorandum  from  the  Coast  Guard  Commandant  to  the  Secretary 
of  Transportation,  via  the  Deputy  Secretary,  was  approved  as  the  selection  plan.  The 
selection  plan,  dated  7  February  1980,  contained  recommendations,  an  acquisition 
schedule  and  nominations  for  the  Source  Evaluation  Board  members.  Two  documents 
followed  which  completed  the  selection  plan.  "Source  Evaluation  Board  Procedures  for 
Evaluating  Proposals"  was  distributed  on  16  June  1980.  And,  a  letter  assigning  the 
SEB  evaluation  teams  was  signed  on  14  July  1980. 

As  I  mentioned  in  the  model,  work  on  the  request  for  proposal  may  begin 
prior  to  the  approval  of  the  selection  plan.  That  is  exactly  what  occurred  in  this 
acquisition.  A  draft  RFP  was  sent  out  to  industry  for  comments  of  5  December  1979, 
five  months  before  the  selection  plan  was  written.  The  final  RFP  was  released  to 
bidders  on  7  June  1980.  Solicitation  phase  activities  are  shown  in  Figure  5.2. 


3E.M.  Fiegel,  "Trip  Report  of  2  Juiv  1986",  summarv  of  an  interview  with  Dr. 
Joseph  Dicenzaf  project  officer  for  the  original  standard  terminal  acquisition.  3  July 


1986. 
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Figure  5.1  Standard  Terminal  Planning  and  Approval  Phases. 
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4.  The  Evaluation  Phase 

The  evaluation  phase  began  after  the  deadline  for  proposals  had  passed.  A 
total  of  seven  proposals  were  received  by  the  closing  date,  2  December  1980. 
Evaluations  by  the  SEB  teams  commenced  soon  after  that.  Operational  capability 
demonstrations  began  on  9  March  1981  and  continued  through  30  March  1981. 
Contractors  were  each  scheduled  for  a  2  day  demonstration. 

Efforts  of  the  Source  Evaluation  Board  teams  were  delayed  by  job 
responsiblities  of  the  team  members.4  Interruptions  and  delays  in  SEB  team  meetings 
at  headquarters  had  an  adverse  impact  on  the  effectiveness  of  the  SEB  teams. 

More  serious  problems  were  to  come.  The  final  months  before  contract  award 
brought  a  major  turnover  in  project  personnel.  Military  transfers  and  a  retirement 
removed  the  acquisition  leaders  from  the  project  and  left  less  experienced  people  to 
take  their  places.  Although  the  majority  of  the  acquisition  milestones  had  been 
achieved,  it  is  obvious  that  the  turnover  affected  the  initial  distribution  and 
management  of  the  standard  terminal. 

5.  The  Selection  Phase 

Preliminary  reports  from  the  SEB  on  the  evaluations  were  made  to  the  SSO. 
On  23  March  1981,  the  SSO  approved  “an  optional  approach  to  competitive  range". 
Although  the  document  explaining  this  approach  was  not  found  in  the  acquisition  file, 
it  appears  to  be  the  SSO's  determination  of  contractors  within  the  competitive  range 
for  contract  negotiations.  With  the  determination  of  competitive  range  the  selection 
phase  began. 

For  various  reasons,  technical  noncompliance,  failure  of  the  OCD,  or  late 
submission  of  their  proposal,  the  number  of  bidders  going  into  contract  negotiations 
was  reduced  to  two.  14  May  1981  was  the  deadline  for  best-and-final  offers  for  this 
contract.  Final  Source  Evaluation  Board  review  was  completed  on  8  June  1981,  and 
the  contract  for  hardware,  software  and  support  services  was  award'd  to  C3. 
Incorporated  on  29  June  1981  for  services  estimated  at  S45.4  million.  It  was  a  firm 
fixed  price  requirements  contract  with  options  to  renew  annually.  Procurements  from 
the  contract  to  be  allowed  for  a  maximum  of  60  months  and  maintenance  support 
services  for  up  to  120  months.  Contract  award  came  more  than  a  year  later  than  the 
acquisition  schedule  in  the  7  February  1980  selection  plan,  and  at  more  than  seven 

4Telephone  interview  with  LCDR  Tim  Fowler,  Coast  Guard  Headquarters,  19 
June  1986.  M 


times  the  cost  estimated  in  the  agency  procurement  request.  Significant  activities  in 
the  evaluation  and  selection  phases  are  shown  in  Figure  5.3. 

6.  The  Implementation  Phase 

After  contract  award,  some  hardware  and  software  were  distributed  to  various 
sites  by  program  managers.  Application  software  was  slow  to  be  distributed  due  to 
development  delays.  Development  software  available  to  users  was  utilized  in  producing 
various  local  applications.  However,  in  some  cases  the  hardware  went  untouched 
because  the  sites  were  not  adequately  prepared  to  use  it.  The  standardization  discussed 
in  the  C3/IRM  Plan  has  been  slow  in  becoming  a  reality. 

Realizing  that  better  acquisition  justification  was  necessary,  a  Commandant 
Instruction  addressing  the  issue  was  distributed  to  the  Coast  Guard  [Ref.  13].  The 
instruction  requires  justification  documentation  to  be  submitted  with  the  procurement 
requests  for  any  ADP  acquisition  from  any  source  for  less  than  550,000,  or  for  any 
ADP  acquisition  procured  from  the  standard  terminal  contract.  Copies  of  the 
justification  documentation  must  be  kept  in  a  system  acquisition  file.  Systems 
procured  prior  to  the  date  of  the  Commandant  Instruction  were  required  to  work  up 
adequate  documentation  to  place  in  their  acquisition  file,  Although  no  approval  was 
required.  This  justification  process  of  existing  systems  identified  under-utilized  and 
unused  equipment  for  redistribution  to  sites  with  documented  needs. 

7.  The  Iterative  System  Evaluation  Phase 

User  support  was  lacking  after  the  contract  was  awarded.  No  formal 
communications  existed  among  Coast  Guard  users.  Furthermore,  there  was  no 
effective  liaison  between  the  Coast  Guard  and  the  vendor  for  user  support. 

The  Systems  Management  and  Engineering  Facility  (SMEF)  at  Station 
Alexandria,  Virginia  was  tasked  with  the  configuration  management  duties  for  the 
standard  terminal.  SMEF  also  provides  the  liaison  between  the  Coast  Guard  and  C3 
Incorporated.  Also,  the  information  center  concept  was  introduced  to  establish  formal 
communications  channels  within  the  Coast  Guard.  Information  centers  are  set  up  at 
each  Coast  Guard  District  office  and  Headquarters  as  a  central  contact  point  in  their 
respective  areas.  Information  centers  are  used  by  users  seeking  assistance.  They  also 
disseminate  Coast  Guard  ADP  policy  to  the  standard  terminal  users. 

Otherwise,  the  iterative  system  evaluation  phase  has  consisted  mainly  of 
studies  necessary  to  eventually  replace  the  existing  standard  terminal  systems  and  their 
support. 


•  April  1985  -  Feasibility  Study5 

•  August  1985  -  Procurement  Plan6 

•  February  1986  -  Software  Conversion  Study7 

•  April  1986  -  Functional  Requirements8 

•  May  1986  -  Acquisition  Support  Plan  (draft)9 

•  May  1986  -  Comparative  Cost  Analysis10 

System  evaluations  can  occur  at  many  levels.  Considering  the  standard 
terminal  as  a  Coast  Guard  system,  a  system  review  would  evaluate  how  the  standard 
terminal  meets  the  needs  of  the  Coast  Guard.  System  reviews  of  major  applications 
should  also  be  done  to  determine  how  effectively  the  standard  terminal  is  fulfilling  the 
requirements  of  the  application.  Finally,  a  system  review  can  be  performed  for  a  single 
site,  like  a  group  office  or  ship.  Reviews  of  this  sort  would  determine  the  adequacy  of 
the  resource  in  an  office  or  stand  alone  environment. 

Although  some  systems  have  been  evaluated,11  it  does  not  appear  that  a 
periodic  post-installation  audit  occurs  on  a  formal  basis  for  most  systems.  However, 
brief  site  evaluations  are  done  because  users  must  justify  acquisition  and  expansion  of 
their  systems  procured  under  the  standard  terminal  requirements  contract. 

B.  CONTRACT  EXECUTION 

Funding  for  procurement  of  equipment  and  services  from  the  standard  terminal 
contract  has  come  from  the  various  operating  and  support  programs.  After  the 
acquisition  process  was  completed,  RCP's  submitted  by  program  managers  have 


5 Feasibility  Study ,  Standard  Terminal  Re-Competition,  U.S.  Coast  Guard,  Office 
of  Command,  Control,  and  Communications,  April  1985. 

6 Standard  Terminal  Procurement  Plan,  U.S.  Coast  Guard,  Office  of  Command, 
Control,  and  Communications,  August  1986. 

7 Standard  Terminal  Software  Conversion  Study  Final  Report,  Wilson  Hill 
Associates,  Inc.,  Washington,  DC,  18  February  1986. 

o 

Functional  Requirements  for  the  U.S.  Coast  Guard  Standard  Terminal.  Federal 
Computer  Performance,  Evaluation  and  Simulation  Center,  Alexandria.  VA.  April 
1986:  F 

9 Standard  Terminal  Acquisition  and  Support  Plan  (ASP)  Review  Board  Meeting,  29 
May  86,  U.S.  Coast  Guard,  Commandant  (G-Tt)  Memorandum  10550,  9  May  1986. 

10  U.S.  Coast  Guard  Standard  Terminal  Replacement  Cost  Analysis,  Comparative 
Cost  Analysis,  American  Management  Systems,  Arlington,  VA,  27  May  1986. 

nThe  13th  Coast  Guard  District  has  conducted  at  least  two  district  wide  studies. 
Thirteenth  District  United  States  Coast  Guard  Standard  Terminal  Survey.  29  June  1984 
and  Thirteenth  District  United  States  Coast  Guard  Computer  Users  Survey  19S5,  23 
October  1985. 
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included  funds  for  procurement  of  standard  terminals.  The  Coast  Guard  uses  this 
rationale  to  justify  the  claim  that  this  project,  with  an  estimate  of  S45.4  million  at 
contract  award,  did  not  fall  under  secretarial  review.  Procurement  was  broken  up  into 
smaller  purchases  by  the  many  programs.  The  Coast  Guard  reasons  that  they  merely 
provided  the  technical  expertise  in  acquiring  the  ADP  capability  for  the  programs  to 
use  as  necessary.  Therefore,  it  was  in  fact  many  smaller  systems  that  were  procured 
rather  than  one  large  Coast  Guard  system.  Both  sides  could  present  valid  arguments, 
however,  this  rationale  was  used  successfully  to  complete  the  acquisition  and  secure 
funding  for  the  standard  terminal. 

The  standard  terminal  contract  has  been  renewed  annually  over  the  past  5  years. 
Because  of  the  changing  Coast  Guard  requirements  and  technology  improvements,  the 
contract  has  been  modified  many  times,  35  modifications  by  20  November  1985. 
Modifications  have  added  and  deleted  equipment  and  services  from  the  contract.  Price 
adjustments  have  also  occured  as  a  result  of  negotiations  with  C3.  Incorporated.  A 
significant  modification  was  issued  on  30  October  1985.  The  maximum  order  limit  on 
hardware  items  (terminals,  storage  devices,  printers)  was  increased  to  correspond  with 
the  maximum  limits  allowed  in  the  delegation  of  procurement  authority  from  GSA. 

By  1  July  1986  an  estimated  S66.6  million  had  been  spent  on  procurements  from 
the  standard  terminal  contract.  Because  standard  terminal  equipment  was  not  accepted 
until  September  1982,  the  5  year  procurement  contract  with  C3,  Incorporated  is  not 
expected  to  expire  until  September  1987. 


VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


In  the  first  chapter  I  outlined  the  purpose  for  conducting  the  research  into  this 
particular  subject,  to  provide  lessons  learned  from  the  original  standard  terminal 
acquisition.  I  have  avoided  in-depth  contracting  issues  because  of  my  limited 
knowledge  and  experience  in  that  field. 

Several  studies  have  been  conducted  which  have  resulted  in  recommendations  to 
improve  the  acquisition  process  and  to  provide  more  effective  management  of  standard 
terminal  systems.  Others  have  written  their  own  lessons  learned  letters  and  documents 
which  have  pointed  out  shortcomings  in  the  management  and  acquisition  process. 
Those  studies  are  listed  among  other  reference  material  in  the  bibliography.  It  seemed 
inappropriate  and  redundant  to  restate  recommendations  and  conclusions  presented  in 
other  studies.  Rather,  I  chose  to  limit  my  findings  to  significant  management  and 
acquisition  issues  which,  in  my  opinion,  have  not  been  adequately  documented  or 
considered. 

A.  SYSTEMS  MANAGEMENT  ENGINEERING  FACILITY 

Conclusion:  SMEF  provides  significant  management  functions  and  user  support  that  was 

previously  nonexistent  or  inadequate. 

After  the  acquisition  of  the  Coast  Guard  Standard  Terminal  was  completed,  the 
system  was  not  effectively  managed  with  regard  to  user  support.  Convergent 
Technologies  and  C3,  Incorporated  were  swamped  with  calls  from  users.  Calls  ranged 
from  inexperience  problems  from  new  users  to  software  and  hardware  enhancement 
suggestions.  There  was  virtually  no  control  over  direct  communication  with  the 
equipment  supplier.  Realizing  that  a  more  controlled,  effective  approach  was  necessary 
the  Coast  Guard  appointed  a  Systems  Management  and  Engineering  Facility,  currently 
at  Coast  Guard  Station  Alexandria,  Virginia,  as  the  direct  liaison  for  the  Coast  Guard 
to  the  equipment  manufacturers  and  suppliers.  Support  requests  and  complaints  work 
their  way  up  from  the  users  to  a  central  point  at  the  cognizant  Coast  Guard  district  or 
Headquarters  information  center.  Requests  reaching  this  point  are  sorted  out.  Those 
requests  that  can  be  handled  at  this  level  go  no  further.  Others  that  are  beyond  the 
scope  of  the  information  center  are  funneled  up  to  SMEF.  SMEF  advisors  and 
specialists  typically  have  the  knowledge  and  experience  to  immediately  assist  with 
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support  requests  at  their  level.  If  not,  they  have  the  resources  and  authority  to  work 
out  a  solution  on  their  own  or  in  coordination  with  the  equipment,' services  suppliers 
and  manufacturers.  Centralized  user  support  and  support  documentation  provided  by 
SMEF  reduce  the  administrative  burden  on  everyone  involved  in  the  process.  It  also 
saves  time  in  the  identification  and  solution  of  problems  since  they  need  only  be  solved 
once  rather  than  many  times.  An  electronic  bulletin  board  has  been  established  to 
provide  easier  communications  with  SMEF. 

SMEF  also  provides  the  same  type  of  support  with  configuration  management. 
The  program  managers,  project  officers,  equipment  suppliers,  users  and  SMEF  itself 
submit  change  proposals  for  hardware  and  software.  Evaluation,  approval  or 
disapproval,  documentation,  change  management  and  monitoring  the  status  of  changes 
are  all  configuration  management  functions,  of  the  Systems  Management  and 
Engineering  Facility. 

The  establishment  of  the  SMEF  was  an  extremely  valuable  move  for  the 
management  of  the  Coast  Guard  Standard  Terminal.  SMEF  evaluates,  approves  and 
distributes  new  software  releases.  It  acts  as  the  technical  liaison  for  the  Coast  Guard 
in  matters  concerning  the  standard  terminal.  Configuration  management  is 
administered  by  the  competent  group  of  individuals  that  make  up  that  organization. 
Without  SMEF  providing  its  support  and  guidance,  the  standard  terminal  concept 
would  not  have  attained  the  level  of  use  and  acceptance  that  it  has. 

B.  FUNDING 

Conclusion:  Because  no  funds  were  budgeted  for  the  original  standard  terminal 
acquisition,  phases  of  the  acquisition  were  altered  to  take  advantage  of  money  when  it  was 
available. 

Throughout  the  acquisition  process  a  constant  concern  is  the  cost  of  the  system. 
Beginning  in  the  planning  phase,  the  feasibility  study  provides  a  gross  cost  estimate, 
possibly  only  the  order  of  magnitude.  Submissions  to  the  ADP  Plan  provide  the  first 
budget  figures  to  budget  planners  as  the  system  gets  closer  to  reality.  The  mission 
need  statement,  acquisition  papers,  and  agency  procurement  request  require  proposed 
budget  information  before  they  are  approved.  Yet  with  all  the  requirements  to  develop 
budgets  and  spending  plans  the  managers  of  an  acquisition  could  possibly  never  have  a 
budget  commitment.  Contract  award  may  occur  with  no  money  budgeted  for  that 
contract.  Given  the  current  austere  budget  situation  for  the  entire  Government  makes 


this  no  less  surprising.  Why  allow  so  much  time,  effort  and  money  to  go  into  a  project 
that  may  never  be  adequately  funded? 

Program  managers  such  as  the  Office  of  Command,  Control  and 
Communications  have  funds  worked  into  their  budgets  to  perform  the  studies  and 
evaluations  necessary  to  insure  their  programs  provide  an  adequate  level  of  support  to 
their  program  constituents.  Feasibility  studies,  requirements  analysis,  and  conversion 
studies  are  among  the  acquisition  process  studies  which  are  funded  out  of  operating 
and  contingency  dollars  worked  into  those  budgets. 

Even  though  the  acquisition  studies  get  funded  as  the  process  progresses,  there  is 
not  necessarily  a  commitment  to  fund  the  project.  Resource  change  proposals  (RCP) 
are  submitted  and  may  or  may  not  be  approved.  The  acquisition  process  could  still 
continue  after  its  RCP  has  been  denied.  The  original  standard  terminal  acquisition  was 
paid  for  with  money  reprogrammed  by  various  program  managers.  This  caused  phases 
of  the  project  to  be  rushed  to  avoid  funds  from  expiring  at  the  end  of  a  quarter  or 
fiscal  year.  Equipment  was  also  paid  for  out-of-hide  or  by  using  money  budgeted  for 
office  equipment. 

To  avoid  repeating  this  scenario  there  should  be  milestones  in  the  acquisition 
process  that  correspond  to  milestones  in  the  budget  process.  A  project  should  not  be 
allowed  to  continue  without  a  budget  commitment.  At  the  time  the  initial  acquisition 
paper  is  approved,  the  Department  of  Transportation  should  take  on  the  commitment 
to  fund  the  project,  at  least  partially. 

Recommendation:  Acquisition  milestones  should  coincide  with  budget  process  milestones 
to  insure  adequate  funding  is  available  for  contract  execution. 

C.  EVALUATION  TEAMS 

Conclusion:  Unnecessary  interruptions  and  delays,  due  to  other  duties  and  job  obligations, 
adversely  affected  the  efforts  of  the  SEB  teams. 

Teams  made  up  of  members  of  the  Source  Evaluation  Board  and  advisors 
evaluate  offerers  proposals.  The  selection  plan,  prepared  by  the  contracting  officer  in 
coordination  with  the  responsible  program  office,  explicitly  identifies  each  member  of 
the  Source  Evaluation  Board.  Prior  to  including  someone  on  the  SEB,  it  should  be 
determined  whether  or  not  that  person  will  be  able  to  devote  the  necessary  time  to  the 
board.  Members  and  their  bosses  should  realize  that  Source  Evaluation  Board  duties 
take  priority  over  normal  duty  assignments. 


Several  of  those  interviewed  mentioned  problems  and  delays  in  getting  their  team 
members  together  at  times  during  the  original  standard  terminal  acquisition.  Team 
members  attended  team  meetings  at  headquarters  in  Washington,  DC.  Most  team 
members  were  stationed  at  headquarters.  While  this  sounds  convenient  on  first 
consideration,  it  sometimes  hindered  the  efforts  of  the  teams.  First  of  all,  team 
members  at  headquarters  often  find  it  difficult  to  ignore  normal  duties.  Their  co¬ 
workers,  both  senior  and  subordinate,  may  also  find  it  difficult  to  allow  team  members 
to  devote  full  time  and  attention  to  the  Source  Evaluation  Board.  Distractions  and 
delays  were  caused  by  this  situation. 

Avoiding  this  situation  would  allow  the  Source  Evaluation  Board  members  to 
perform  their  duties  at  their  own  pace,  undisturbed.  Sending  the  SEB  members  on 
temporary  assigned  duty  (TAD)  would  provide  them  with  the  job  isolation  necessary. 
Temporary  duty  at  a  private  meeting  place  could  cost  more  money  than  available,  plus 
it  might  be  difficult  to  justify.'  Perhaps  TAD  to  Station  Alexandria  Virginia  would  be 
the  best  solution.  Members  would  be  isolated  from  their  jobs,  unless  team  members 
were  from  Station  Alexandria.  Station  Alexandria  is  convenient  to  headquarters,  which 
would  avoid  costly  travel  and  per  diem  expenses.  Because  Station  Alexandria  is  a 
Coast  Guard  unit,  team  members  would  not  lose  the  benefit  of  operational  and 
administrative  support.  Communications  facilities  are  also  available.  Finally,  some  of 
the  most  knowledgeable  computer  people  in  the  Coast  Guard  are  stationed  at  Station 
Alexandria.  This  could  be  advantageous  if  it  becomes  necessary  to  seek  advice  outside 
of  the  SEB  evaluation  team. 

Recommendation:  Isolation  of  the  SEB  teams  away  from  their  jobs  should  be  allowed 
during  evaluation  periods. 

D.  EXPERIENCE  AND  TRAINING 

Conclusion:  Project  officers  play  the  most  important  role  in  determining  whether  or  not 
an  acquisition  project  effectively  achieves  its  intent  within  time  and  budget  constraints. 

It  is  obvious  that  the  Government  is  concerned  that  the  big  money  which  is 
spent  on  major  systems  should  be  managed  effectively.  A  recent  amendment  to  Title 
10,  U.S.C.  Section  85.1622,  requires  that  program  managers  in  Department  of  Defense 
major  systems  acquisitions  have  a  minimum  of  eight  years  experience  in  related 
technical  fields  and  acquisition  [Ref.  14:  p.  9].  Although  the  cost  and  scope  of  the 
intended  DOD  major  systems  far  exceed  that  of  the  standard  terminal,  proper 
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management  and  control  techniques  will  help  projects  achieve  success  within  minimum 
cost  and  time  regardless  of  the  size.  Experience,  training  and  education  are  three 
factors  that  will  benefit  the  program  manager  in  fulfilling  his/her  responsibilities. 

At  the  time  of  the  original  standard  terminal  acquisition,  its  project  officer  had 
very  little  experience  in  the  ADP  field.  He  was  a  general  line  officer  in  the  Coast 
Guard  with  a  one  week  ADP  course  behind  him.  His  acquisition  experience  with  ADP 
was  more  extensive,  however.  He  oversaw  the  network  procurement  resulting  in  the 
GTE  Telenet  service  contract,  and  participated  in  a  minicomputer  acquisition  for  the 
Operations  Computer  Center  at  Governor's  Island,  NY.  In  fact,  there  were  very'  few 
people  fully  qualified  to  manage  a  large  integrated  microcomputer  acquisition  because 
a  project  of  this  scale  with  micros  had  never  been  done  before. 

Now  ADP  experience  is  available  in  the  Coast  Guard.  The  Coast  Guard  should 
utilize  its  personnel  where  they  can  contribute  the  most  to  the  service.  Project  officers 
should  be  selected  on  the  basis  of  experience,  education  and  willingness  to  perform  the 
job,  not  merely  to  fill  an  open  billet. 

Recommendation  1:  Project  officers  should  be  selected  based  on  experience,  education , 
training  and  enthusiasm  for  the  project. 

Recommendation  2:  ADP  oriented  career  paths  should  be  formally  developed  to  insure  an 
adequate  pool  of  officers  is  available  with  the  necessary  experience  to  manage  the  Coast 
Guard’s  C3i  l RM  programs. 

E.  PROJECT  PERSONNEL  CONTINUITY 

Conclusion:  The  original  standard  terminal  acquisition  team  was  broken  up  during  a 
critical  time  before  the  acquisition  was  complete. 

One.  of  the  most  recurring  comments  made  during  interview’s  was  the  lack  of 
continuity  in  the  management  of  the  original  standard  terminal  acquisition.  The 
project  was  driven  by  the  enthusiasm  and  foresight  of  a  few  Coast  Guard  officers. 
Their  job  was  monumental  considering  the  scope  of  the  project  they  undertook,  not  to 
mention  the  new  technology  concerned.  The  management  team  began  breaking  up 
because  of  military  transfers  and  discharges  shortly  before  the  project  was  completed. 
Relatively  inexperienced  personnel  were  put  into  top  positions  to  finish  up.  During  the 
transition  much  of  the  documentation  and  expertise  were  lost. 

It  seems  like  such  a  basic  idea,  to  put  a  team  in  to  work  on  a  project  and  leave 
them  there  until  the  project  is  done.  Although  transition  is  inevitable  in  the  military. 


scheduling  the  transfer  of  personnel  to  avoid  the  critical  stages  of  an  acquisition  would 
avoid  unnecessary  problems  in  an  already  complicated  process. 

Except  in  cases  where  the  project  officer  is  carrying  out  his/her  responsibilities 
unsatisfactorily,  the  project  officer  should  see  the  project  through  to  completion.  If 
that  is  not  possible,  sufficient  relief  time  should  be  allowed  for  the  successor  to  benefit 
from  the  experiences  and  lessons  of  the  predecessor. 

Recommendation:  The  acquisition  team,  especially  the  project  officer,  should  remain  with 
an  acquisition  until  the  project  is  finished. 

F.  REGULATIONS 

Conclusion:  Information  concerning  A  DP  acquisitions  is  difficult  to  gather  because  of  the 
numerous  sources,  some  of  which  are  outdated. 

Research  into  the  acquisition  of  ADP  equipment  and  services  was  a  very 
enlightening  and  frustrating  experience.  Regulations  and  requirements  concerning  the 
federal,  Department  of  Transportation  and  Coast  Guard  acquisition  processes  are 
spread  throughout  numerous  documents  and  publications.  The  majority  of  Federal 
acquisition  information  related  to  ADP  is  contained  in  the  Federal  Information 
Resources  Management  Regulations  which  is  published  by  the  General  Services 
Administration.  That  publication  is  in  a  s«nse  the  bible  to  which  all  Government 
agencies  must  conform  in  ADP  matters.  The  Department  of  Transportation  has  DOT 
Orders  that  are  outdated,  contradictory  and  confusing.  The  Coast  Guard  directives 
c.onceming  ADP  are  no  better.  It  does  not  seem  unreasonable  to  expect  the  Coast 
Guard  ADP  Management  Manual  to  be  a  useful  source  of  information  in  a  research 
projects  such  as  this  thesis.  It  was  not. 

The  Department  of  Transportation  and  the  Coast  Guard  should  undertake  a 
comprehensive  review  of  their  publications.  Benefits  such  as  more  up-to-date  and 
comprehendable  information  would  assist  those  personnel  with  the  need  for  that 
information.  After  all,  of  what  good  is  an  outdated  publication? 

The  Department  of  Defense  has  more  regulations  for  ADP  acquisition  than  DOT 
and  the  Coast  Guard  combined.  DOD  does,  however,  have  an  ADP  Supplement  to 
the  Federal  Acquisition  Regulations.  Such  a  supplement  to  the  Transportation 
Acquisition  Regulations  (TAR)  would  certainly  help  to  eliminate  any  ambiguity  or 
confusion  on  the  requirements  for  ADP  acquisition.  The  research  for  a  TAR 
Supplement  covering  the  acquisition  of  ADP  resources  need  only  be  done  once,  rather 
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than  repeating  the  drill  each  time  an  acquisition  commences.  A  step-by-step 
acquisition  process  that  can  be  tailored  to  individual  projects  should  be  developed  and 
published.  Regulations  mandate  the  legal  and  proper  process  to  acquire  ADP 
resources.  Having  to  search  through  volumes  of  regulations  in  various  places  increases 
the  probability  that  something  will  be  left  out,  ignored  or  forgotten. 

Recommendation:  A  single  reference  document  for  Department  of  Transportation  ADP 
acquisitions  should  be  developed  and  frequently  updated. 

G.  STANDARDIZATION  AND  COMPATIBILITY 

Conclusion:  Nonstandard  microcomputers  can  be  procured  with  little  consideration  of  the 
standard  terminal  requirements  contract. 

Standardization  is  one  of  the  most  important  concepts  behind  the  acquisition  of 
the  Coast  Guard  Standard  Terminal.  A  few  foresighted  Coast  Guard  officers  saw  the 
need  for  choosing  a  single  type  of  hardware  that  would  be  able  to  support  the  various 
Coast  Guard  applications  at  that  time  and  into  the  future.  Microcomputers  were  just 
starting  to  come  out  and  many  organizations  including  the  Coast  Guard  were 
scrambling  to  capitalize  on  their  capabilities.  Standardization  back  then  has  led  the 
Coast  Guard  to  its  success  with  microcomputers  today. 

The  standard  terminal  contract  is  a  requirements  type  contract.  That  means  that 
any  application  which  can  be  satisfied  by  the  hardware,  software  and/or  services  in  the 
contract,  must  use  the  contract  as  the  source  for  its  procurement.  If  adequate 
justification  is  provided  to  acquire  ADP  equipment,  other  than  that  on  the  contract, 
the  Coast  Guard  typically  grants  approval.  In  some  cases  the  justification  provided 
should  not  warrant  approval,  although  it  sometimes  does.  While  researching  my  topic, 
one  headquarters  office  convincingly  proved  this  point.  The  office  managed  a  large 
minicomputer  for  approximately  100  users.  Justification  was  approved  and  money 
provided  for  acquisition  of  a  Coast  Guard  Standard  Terminal  for  that  office.  The 
microcomputer  was  never  really  used  and  was  soon  given  to  another  office  that  had  a 
need  for  it.  Later,  justification  from  the  same  office  that  had  recently  given  away  a 
standard  terminal,  was  approved  for  the  purchase  of  an  Apple  Macintosh. 

Stringent  justification  criteria  should  be  required  before  allowing  acquisition  of 
ADP  equipment  and  services  not  appearing  on  the  requirements  contract. 
Proliferation  of  noncompatible  micros  was  the  original  intent.  Now  that  the  Coast 
Guard  has  such  a  considerable  investment  in  the  Convergent  Technologies  micros,  it 
should  be  doubly  important  that  our  computers  remain  compatible. 


Recommendation:  The  Coast  Guard  should  apply  more  stringent  justification  criteria 
before  approving  requests  for  noncompatible  microcomputers. 

H.  PERIODIC  SYSTEM  AUDITS 

Conclusion:  Inadequate  reviews  are  conducted  on  installed  systems  to  insure  they  are 
effectively  utilized  and  used  for  purposes  for  which  they  were  justified. 

A  key  consideration,  once  an  ADP  system  is  acquired,  is  to  periodically  evaluate 
the  system  to  insure  its  adequacy.  It  cannot  be  emphasized  enough  as  to  how 
important  this  iterative  review  cycle  is.  After  implementation,  the  system  should 
continue  to  perform  its  proposed  functions  satisfactorily.  If  not,  redesign  or 
reclassification  of  the  system  should  occur.  The  goal  of  the  acquisition  process  is  to 
provide  a  system  that  satisfies  the  needs  of  the  users  at  lowest  overall  cost  to  the 
government.  A  system  not  being  used  to  its  potential  or  so  seriously  incapable  that  it 
is  not  used,  must  be  reevaluated.  Periodic  evaluations  prevent  a  system  from  becoming 
either  of  the  two  extreme  examples  mentioned. 

Performing  a  periodic  system  review  is  typically  not  done  on  Coast  Guard 
systems,  even  though  it  is  recommended  and  desireable.  System  growth,  for  the  most 
part,  has  been  determined  by  a  select  few  knowledgeable  users  or  system  managers  who 
have  an  idea  of  what  they  want  the  system  to  do.  Use  and  acceptability,  however-,  is 
determined  solely  by  the  system  users.  Therefore,  periodic,  formal  reviews  should  be 
scheduled  and  performed  to  insure  ADP  systems  are  effectively  and  efficiently  meeting 
the  needs  of  users,  managers  and  the  Coast  Guard  as  a  whole.  This  program  should  be 
the  responsibility  of  the  program  manager  sponsoring  the  ADP  system.  Results  should 
be  reportable  to  the  Command,  Control  and  Communications  support  manager  (G-T). 
Considering  the  rapid  rate  of  change  in  ADP  technology,  the  frustratingly  slow 
acquisition  process  and  the  continuing  evolution  of  Coast  Guard  missions,  a  biennial 
review  cycle  would  suffice  on  a  trial  basis  until  a  review  provides  a  basis  for  a  better 
audit  interval. 

Recommendation:  Periodic  system  reviews  should  be  done  at  every  ADP  site  and  for  each 
of  the  major  applications  to  insure  proper  resource  utilization  and  cost  effectiveness. 

I.  ACQUISITION  DOCUMENTATION 

Conclusion:  Inadequate  documentation  exists  from  the  original  standard  terminal 
acquisition. 


Documentation  in  the  acquisition  file  for  an  ADP  system  should  include  studies, 
correspondence  and  just  about  anything  else  that  concerns  the  particular  system.  One 
source,  more  than  any  other,  documents  the  life  cycle  of  a  system,  the  acquisition 
paper.  It  has  been  the  practice  of  the  Coast  Guard  to  decide  on  its  own  whether  or 
not  an  acquisition  paper  is  submitted  for  proposed  ADP  systems.  Avoiding 
unnecessary  levels  of  bureaucracy  is  a  valid  concern  in  these  days  of  acquisition  delays 
due  to  the  many  levels  of  approval  necessary.  The  acquisition  paper  approval  process 
may  be  waived  if  it  is  convincingly  proven  that  the  system  does  not  come  under  the 
secretarial  review  process  for  major  syst'ms  acquisition  (MSA)  or  TSARC  program  list 
(TPL).  This  decision,  however,  is  to  made  by  the  Deputy  Secretary  not  by  the  Coast 
Guard.  The  Coast  Guard  can  only  provide  an  convincing  argument. 

An  acquisition  paper  should  still  be  developed,  even  if  it  is  not  required.  In  most 
cases  the  same  general  procedures  should  be  followed  for  smaller  systems  as  larger 
ones.  The  acquisition  paper  format  is  designed  to  contain  most  of  the  necessary 
information  on  the  system's  acquisition.  Changes  in  the  project  are  reflected  so  that 
the  acquisition  paper  always  reflects  the  current  state  of  the  acquisition  as  well  as  an 
accurate  account  of  what  has  occured  to  that  point  in  time.  Preparing  an  acquisition 
paper  should  not  be  considered  just  another  bureaucratic  exercise.  Rather,  it  should  be 
realized  as  the  systems  planning  and  documentation  tool  that  it  is  intended  to  be.  Had 
an  acquisition  paper  been  done  for  the  original  standard  terminal  acquisition, 
subsequent  ADP  acquisition  projects  throughout  the  Government  could  have  tailored 
and  fine  tuned  their  microcomputer  acquisition  projects  from  it.  The  biggest  benefit  of 
all  would  have  been  to  the  Coast  Guard  at  this  point  in  time  when  replacement 
systems  are  under  consideration. 

Recommendation:  To  insure  systems  planning  and  documentation  are  satisfaclorally  done . 
an  acquisition  paper  should  be  developed  and  maintained  for  future  acquisitions. 

J.  DEVELOPMENT  TOOLS  AND  APPLICATIONS 

Conclusion:  Poor  initial  planning  for  applications  software  has  left  Coast  Guard  users 
with  hardware  and  software  tools  that  they  do  not  know  how  to  effectively  use. 

After  five  years  of  the  standard  terminal  the  Coast  Guard  should  strive  to 
accomplish  one  of  its  primary  objectives  of  the  C3  1RM  architecture.  Data  should  be 
shared  and  accessed  more  readily.  Program  managers  should  determine  what  data  and 
applications  are  necessary  for  their  constituency.  Specifications  for  the  applications 
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could  be  gathered  from  users  in  the  field  who  have  developed  their  own  systems.  The 
benefits  of  lessons  learned  from  many  development  efforts  reduce  the  probability  of 
encountering  the  same  problems. 

The  standard  terminal  was  intended  to  be  a  tool  for  users  to  access  and  utilize 
Coast  Guard  data.  Development  software  is  provided  at  no  extra  cost  when  hardware 
is  delivered  to  sites.  Many  users  and  some  system  managers  are  overwhelmed  by  the 
number  of  software  and  hardware  tools  available  to  them  that  they  do  not  know  how 
to  use.  Others  are  off  and  running  with  whatever  is  available  to  them.  Instead  of 
putting  their  systems  to  use  in  ways  intended  by  the  C3/IRM  architecture,  ambitious 
users  spend  time  attempting  to  automate  unnecessary  and  trivial  tasks,  or  trying  to 
learn  how  to  use  what  is  provided  to  them. 

The  Coast  Guard  is  not  in  the  business  of  training  programmers  and  systems 
developers.  Rather  the  Coast  Guard  is  attempting  to  utilize  the  C3  architecture  to  its 
fullest  potential  to  achieve  predetermined  goals.  Yet  the  delays  in  getting  standard 
applications  software  into  the  field  have  forced  users  to  innovate  in  order  to  make  use 
of  the  standard  terminal.  Consequently,  programs  developed  by  local  innovators 
typically  are  poorly  planned,  inadequately  documented  and  virtually  unmaintainable. 
The  heirs  to  these  applications  are  in  a  difficult  position.  They  do  not  know  how  the 
programs  work  or  if  the  results  they  provide  are  accurate.  In  most  cases  the  costs 
exceed  the  benefits  associated  with  this  type  of  development  approach.  Instead  of 
being  a  useful  tool,  the  standard  terminal  has  occasionally  been  a  time  and  effort  sink. 
A  Coast  Guard  report  points  out  that  several  mid-level  managers  have  adversely 
affected  their  careers  by  becoming  too  involved  in  attempting  to  automate  too  many 
things  [Ref.  15:  p.  4],  These  cases  could  refer  to  the  very  same  innovation  encouraged 
and  applauded  by  failed  planners. 

The  C3  IRM  architecture  emphasizes  standard  software.  More  effort  and 
planning  should  go  into  accomplishing  that.  Adequately  planned  and  successfully 
implemented  applications  will  develop  user  confidence  and  better  acceptance  of  the 
standard  terminal.  Data  integrity  and  usefulness  will  improve  if  unnecessary  data 
conversions  are  eliminated.  Applications  will  benefit  from  standardization  and  a  wide 
user  base  involved  with  using  and  improving  the  system. 

Users  and  developers  are  two  different  groups.  The  standard  terminal  is  targeted 
for  the  Coast  Guard  users.  If  the  Coast  Guard  continues  to  rely  on  internal 
innovation,  it  should  realize  that  those  innovative  efforts  in  programming  and 


implementation  are  using  manpower,  time  and  dollar  resources  that  are  most  likely 
being  diverted  from  other  necessary  missions.  Probably  every  unit  has  had  at  least  one 
experience  with  struggling  to  develop  a  unique  application  or  attempting  to  implement 
another  unit's  development.  Such  efforts  are  obviously  occuring  at  the  wrong  level  of 
the  Coast  Guard  where  inadequate  resources  are  available.  It  may  seem  like  heresy  to 
suggest  that  development  tools  be  withheld  from  Coast  Guard  users,  but  that  may  be 
necessary.  Creativity  and  innovation  will  not  be  suppressed,  we  should  realize  that 
those  innovators  are  still  going  to  be  out  there. 

Software  should  be  made  available  only  after  justification  has  been  approved, 
similar  to  the  hardware  justification.  Some  cost  savings  may  be  realized  by  reducing 
software  licensing  and  distribution.  Iterative  system  reviews  could  be  used  to 
determine  what  software  is  or  is  not  necessary  for  various  sites.  Certainly  much  disk 
space  and  time  will  be  saved  if  several  of  those  personnel  attempting  to  learn  Pascal  or 
Cobol  will  be  forced  to  do  it  at  the  appropriate  time  and  in  the  proper  environment. 
The  proper  environment  could  be  at  home  on  their  own  computer  or  in  school  or 
training  classes,  but  not  at  work  on  Coast  Guard  resources  which  were  not  intended 
for  that  use. 

The  Coast  Guarcf  program  managers  should  develop  support  applications.  These 
applications,  documentation  and  training  should  be  available  to  the  field  units  that 
need  them.  It  is  not  realistic  nor  good  management  practice  to  rely  on  the  field  to 
develop  redundant  data  manipulation  applications  to  satisfy  Coast  Guard  wide 
requirements. 

Recommendation  1:  Program  managers  should  take  a  more  active  role  in  determining  the 
data  and  applications  requirements  for  their  constituency. 

Recommendation  2:  To  avoid  proliferation  of  unmaintainable  locally  developed 
applications,  development  software  (such  as  Pascal,  Cobol  and  database  software)  should 
not  be  distributed  with  every  system. 

K.  CHANGING  COST  OF  TECHNOLOGY 

Conclusion  I:  A  DP  hardware  prices  have  continued  to  decline  as  technology  improves. 
Conclusion  2:  Modifications  to  the  standard  terminal  contract  have  allowed  the  Coast 
Guard  to  take  advantage  of  price  reductions  and  improved  technology. 

Historically  hardware  prices  have  decreased  as  technology  progressed. 
Technological  improvements  like  more  efficient  memory  or  increased  processor  speeds 


continually  cause  relatively  new  hardware  to  fall  behind  the  state-of-the-art,  and  old 
hardware  to  become  obsolete. 

A  fixed  price  requirements  contract  for  ADP  systems  hardware  over  a  multiyear 
time  period  locks  the  Coast  Guard  into  fixed  prices  for  hardware  as  prices  fall  and  the 
contracted  technology  falls  further  behind  the  power  curve.  Essentially  paying  more 
for  less.  This  is  particularly  wasteful  if  the  majority  of  the  procurements  under  the 
contract  occur  in  later  years.  The  existing  standard  terminal  contract  has  been 
modified  to  reduce  prices  for  hardware  and  to  replace  older  equipment  listed  in  the 
contract  with  more  current  items. 

Recommendation  1:  A  clause  seeking  periodic  negotiated  reductions  in  hardware  prices 
corresponding  to  technology  advances  should  be  included  in  the  contract  if  possible. 
Recommendation  2:  Incentives  should  be  offered  to  bidders  to  add  or  modify  hardware  in 
the  c.  ntract  as  new  technology  becomes  available  and  economically  affordable. 

L.  CONTRACT  INTERPRETATIONS 

Conclusion:  Inadequate  acquisition  documentation  and  contract  specifications  have  left  the 
standard  terminal  contract  open  to  interpretations. 

At  the  time  of  the  standard  terminal  contract  award  no  formal  contract 
document  existed.12  The  contract  was  put  together,  after  the  award,  from  documents 
that  existed  on  a  word  processor.  C3,  Incorporated,  the  successful  bidder,  did  not  have 
a  contract  until  it  was  provided  later. 

•Significant  contract  interpretations  have  occurred  since  the  award  in  June  1981. 
Under  the  contract,  procurement  of  hardware  was  to  be  allowed  for  5  years.  That 
would  lead  us  to  conclude  that  no  procurement  of  hardware  would  be  allowed  after 
June  1986.  However,  since  no  equipment  was  actually  accepted  until  September  1982, 
the  current  interpretation  is  that  the  procurement  part  of  the  contract  will  not  expire 
until  5  years  from  that  date,  September  1987. 

Furthermore,  the  contract  placed  maximum  order  limits  (MOL)  on  hardware 
which  includes;  keyboard; display  (terminals),  cluster  controllers,  direct  access  and  tape 
storage  devices,  and  printers.  The  differentiation  between  keyboard,  display  and  cluster 
controllers  has  been  lost.  The  standard  terminal  has  the  cluster  controller  capability 
built  in.  Because  of  the  difficulty  in  attempting  to  differentiate  between  the  two,  the 
MOL  for  terminals  was  determined  to  be  the  sum  of  the  MOL's  for  keyboard  display 

12Coa$t  Guard  Headquarters,  interview  with  Office  of  Comptroller.  Procurement 
Division  (G-FCP)  personnel,  21  June  1986. 
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and  cluster  controllers.  The  interpretation  extends  to  the  delegation  of  procurement 
authority  where  the  item  cluster  controller  also  appears. 

It  is  incredible  to  think  that  a  contract  of  major  importance  to  the  entire  Coast 
Guard  could  be  subject  to  such  major  interpretations.  The  lack  of  acquisition 
documentation  precludes  further  investigation  into  the  original  intent.  Requirements 
for  maintaining  acquisition  files  should  be  strictly  enforced  to  avoid  similar  situations 
from  occurring. 

Recommendation:  All  relevant  documentation  should  be  required  enclosures  to  the 
acquisition  file  to  avoid  possible  adverse  interpretation  of  future  contracts. 


APPENDIX  A 
ACQUISITION  PAPER 


(taken  from  DOT  Order  4200.1 4 B) 

1.  Major  System  Identification. 

a.  Description  of  the  mission  need  to  be  satisfied.  (A  copv  of  the  approved 
mission  need  statement  should  be  attached  to  the  AP) 

b.  Name  and  brief  description  of  the  proposed  acquisition  program, 
including  an  explanation  of  how  it  will  improve  transportation. 

c.  A  plan  and  budget  for  obtaining  alternative  system  design  concepts  or  a 
justification,  with  supporting  details,  if  alternative  design  concepts  are  not  to  be 

d.  Identification  of  the  kev  decision  under  consideration.  Complete 
justification  for  waiving  one  or  more  key  decision  points  should  be  included  in 
this  section  of  the  AP. 

2.  Recommendation.  Include  a  positive  recommendation,  i.e..  we  should  proceed 
with  the  acquisition  described  in  this  AP  because  (rationale  supporting  the 
recommendation). 

3.  Program/ Project  Plan.  This  section  of  the  AP  should  contain  a  summarv  cf  the 
applicable  program,  planning  documents  and  should  cite  the  dates  arid  other 
pertinent  iaentriving  data  of  each  document.  (Attach  copies  of  the  documents’ 
as  appropriate). '  This  section  of  the  AP  should  also  include: 

a.  Details  of  initial  program  activities,  including  preliminary  research,  and 
studies,  leading  up  to  the  AP  under  consideration. 

b.  Summary  of  projected  program  activities  through  completion  or 
implementation. 

c.  Status  of  prior  and  current  systems  that  have  a  relationship  to,  but  are 
not  part  of.  the  major  svstem  described  in  the  AP.  Include  anv  known 
programs,  projects,  or  systems  which  are,  or  have  been  directed  toward  similar 
objectives. 

d.  .  Acquisition  cost  estimates,  bv  fiscal  year,  for  each  kev  decision  phase. 
Indicate  whether  the  estimate  is  in  current  vear  or  then  year'  dollars,  and  what 
inflation  factors  were  considered  in  the  estimate. 

e.  Identification  of  the  resources  required  from  all  sources,  including  in- 
house  effort,  contracts,  grants  and  interagencv  agreements.  Indicate  the  “'time 
and  costs  of  in-house  etlorts  separatelv  from  out-of-house  efforts  (contracts, 
grants,  etc.). 

f.  Identification  of  Government  or  commercial  facilitv  needs  which  require 
special  attention  or  approval. 

g.  .Identification  and  evaluation  of  the  major  risks  involved,  including 
technical,  budgetary  and  schedule,  in  achieving  the  goals  of  the  proposed 
program. 

h.  An  identification  of  anv  major  operational  cost,  legal  environmental, 
safety.,  procurement  or  logistical  support  requirements  foreseen  in  the 
acquisition  and  proposed  plans  for  satisfying  these  requirements. 

i.  Indicate  the  extent  of  consideration  given  to  and  anv  approval  obtained 
or  required  relating  to  the  requirements  of  DOT  137U.2A.  Procurement  of  ADP 
Processing  Equipment  and  Services. 
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Acquisition  Plan.  This  section  should  include,  as  a  minimum,  a  discussion  of  the 
following  items: 

a.  Overall  logistics  strategy  to  put  the  system  into  operational  use,  including 
support  requirements  such  as  documentation,  data  collection,  technical  support 
services,  spare  parts,  training,  and  maintenance,  and  installation. 

b.  Procurement  strategy  including  a  discussion  of  the  following  factors  for 
the  phase  under  consideration: 

(1)  Identification  of  all  on-going  and  proposed  contract  efforts,  This 
section  should  include  a  brief  description  of  each  contract  award, 
estimated  cost,  period  of  performance,  proposed  method  of  procurement 
and  contract  tvpe,  anticipated  award  date,  and  contractor  name  (if 
known). 

(2)  Procurement  schedule,  milestones  and  performance  objectives. 

(3)  A  discussion  of  the  consideration  given  to  assuring  competition 
and  achieving  an  appropriate  balance  between  contractor  and 
Government  risk. 

(4)  A  discussion  of  the  feasibility  of  attempting  cost  sharine  or 
otherwise  providing  contractors  with  additional  incentive  to  maximize 
accomplishment  and  cost  control. 

Schedule  Goals.  A  projection  of  schedule  goals  for  the  program  include 
procurement  milestones  including  consideration  ol  the  impact  on  contractors  of 
delay,  if  any,  between  program  phases. 

Economic  Analysis,  Cost-benefit/Cost  Effectiveness  Analysis,  and  Life  Cycle  Costs. 
Summarize  the  analvses  previously  undertaken  and  present  a  projection  of  life 
cycle  costs  for  the  program. 

Special  Funding  Arrangements.  Funds  to  be  provided  to,  or  received  from,  other 
Government  or  public  agencies  and  private  contractors  (cost  sharing,  grants. 


Program  Management.  Designation  of  a  program  manager,  and  identification  of 
the  roles  and  functions  of  all  organizations,  principal  officials  and  kev  personnel 
within  and  outside  of  DOT  who  have  direct  responsibility  for  performance  of 
any  of  the  work  or  for  participating  in  any  of  the  decisions'  called  for  in  the  AP. 
A  description  of  the  proposed  management  control  structure  including 
personnel  resources  and  skills  required.  A  copv  of  the  program  manager  s 
charter  shall  be  attached  to  the  initial  AP. 

Alternative  Acquisition  Actions.  Briefly  describe  the  alternative  strategies  (e.g. 
program  delay,  cancellation,  etc.)  considered  bv  the  Head  of  the  Departmental 
element  prior  to  submission  of  the  AP. 

Technical  Alternatives.  Briefly  describe  all  known  technical  alternatives,  and 
combinations  thereof,  that  have  been  identified  to  date.  This  section  should  be 
very  broad  in  scope  at  kev  decision  one  and  should  narrow  in  focus  as  the 
program  progresses. 

Technical  Addendum.  This  addendum,  normally  one  page,  lists  the  quantifvable 
operational  and  technical  (design)  characteristics  and  the  units  or  measure 
which  best  describe  the  transportation  svstem,  and  which  best  reflect  its 
expected  value  and  effectiveness  in  performing  intended  missions.  This  data 
shall  be  updated  at  each  major  decision  point  to  show  the  current  estimates  for 
the  delineated  characteristics  with  respect  to  earlier  projections.  Operational 
characteristics  normallv  include  reliability  and  maintainability  coals  (svstem  or 
component  mean- time  between  failure  (MTBF)  and  mean-time  to  repair 
(MTTR)).  Technical  characteristics  normally  include  those  salient  parameters 
which  must  be  achieved  (or  the  program  to  meet  its  objectives.  They  include, 
but  are  not  limited  to  factors  such  as  size,  speed,  weight,  performance  envelope. 


13.  Submission  Procedures. 

a.  Prepare  20  copies  of  the  AP. 

b.  .  Transmit  these  copies  to  the  Executive  Secretary  using  the  following 


To:  The  Deputy  Secretary 
Through:  TSARC  (M-60),  Executive  Secretary 
[Ref.  5:  Attachment  3] 


APPENDIX  B 

MAJOR  SYSTEMS  CANDIDATE  MEMO 


( taken  from  DOT  Order  4200. 1 4B) 

Major  System  Acquisition  Candidate:  (Program  Name) 

1.  Brief  statement  of  the  mission  need  to  be  satisfied. 

2.  Identification  or  required  new  capability,  (this  should  be  addressed  in  terms  of 
functional  capabilities  desired  and  not  in  terms  of  hardware  solutions). 

3.  Statement  of  benefit  to  the  Government. 

4.  Status  of  existing  capabilities. 

5.  Resource  requirements,  (including  in-house  resources,  contracts,  grants, 
interagency  agreements,  etc.) 

6.  Time  constraints. 

7.  Status  of  current  planning  activities  for  the  proposed  program,  (identifv  anv 
contract  dollars  expended  to  date,  if  applicable) 

8.  Recommendation  as  to  whether  the  program  should  be  designated  as  a  major 
system  acquisition. 

[Ref.  5:  Attachment  1] 


APPENDIX  C 

MISSION  NEED  STATEMENT 


(taken  from  DOT  Order  1400.14B) 

I.  Mission 

A.  Mission  Area.  Identify  the  major  transportation  problem  to  be  satisfied. 

B.  Mission  Task.  State  the  mission  need  in  terms  of  functional  capabilities 
desired  and  not  in  terms  of  equipment  or  other  means  which  might  satisfy 
the  need. 

II.  Existing  and  planned  capabilities  to  Accomplish  the  Mission  Task. 

A.  Briefly  summarize  the  existing  and  planned  capability  and  inherited  assets 
to  accomplish  the  mission. 

B.  Departmental  elements  as  well  as  other  Government  agencies  involved. 

III.  Assessment  (with  quantification,  whenever  possible).  Assess  the  need  in  one  or 
more  of  the  following  terms. 

A.  Shortfalls  in  an  existing  capability. 

B.  Technological  opportunity. 

.  C.  Physical  obsolescence  of  equipment. 

D.  Cost  savings  Opportunity,  potential  for  life  cycle  cost  savings,  etc. 

E.  Other. 

IV.  Constraints. 

A.  Value  or  worth  of  meeting  the  need. 

B.  Relationship  to  overall  agency  budget. 

C.  Relative  priority  within  the  mission  area. 

D.  Logistics  considerations. 

E.  Environmental  considerations. 

F.  Time  Constraints. 

G.  Maximum  and  minimum  estimates  of  resources  required. 

H.  Other. 

V.  Impact  of  staying  with  the  Present  System. 

A.  Ability  to  fulfill  the  mission. 

B.  Cost  of  increasing  quantity  of  existing  equipment  to  a  level  that  meets  the 
capacity  or  capability  needed. 

C.  Cost  of  maintaining  equipment  with  low  availability  or  cost  of  ownership. 
[Ref.  5:  Attachment  2] 


APPENDIX  D 

PROGRAM  MANAGERS  CHARTER  OUTLINE 

{taken  from  DOT  Order  4200. 14B) 

A.  Introduction. 

1.  Purpose, 'Action  Requested. 

2.  Background. 

3.  Approval. 

B.  Charter. 

1.  System  Description. 

2.  Scope  of  Project. 

3.  Authorities. 

4.  Responsibilities. 

5.  Operating  Relationship. 

6.  Supporting  Organizations. 

7.  Organization  and  Staffing  (including  organization  chart). 
(Ref.  5:  Attachment  4] 
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APPENDIX  E 

QUARTERLY  STATUS  REPORTS 

( taken  from  DOT  Order  4200. 1 4 B) 

1.  Program  Title: 

2.  Report  Period: 

*3.  Overall  Assessment  of  Status: 

*4.  Evaluation  of  Technical  Performance: 

*5.  Evaluation  of  Schedule: 

*6.  Evaluation  of  Cost: 

*  for  item  numbers  3-6  above  the  following  status  codes  are  applicable: 

A  -  On  target 

B  -  Management  Attention 
C  -  Critical 

(Status  code  definitions  are  in  Appendix _ ). 

7.  Major  Achievements  in  Last  Quarter: 

8.  Key  Milestones 

Met: 

Mi$sed: 

9.  Key  Milestones  in  Next  Two  Quarters: 

10.  Financial  Management  Information. 

11.  Key  Problem  Areas  (discuss  potential  impact  and  corrective  action  planned): 

a)  total  program 

b)  prime'contract 

c)  support  contract!  s) 

d)  interfaces  with  other  systems  or  equipment 

12.  Meeting  Conferences,  Program  Reviews 

Summarize  kev  meetings  for  (1)  the  report  quarter,  indicating  purpose, 
attendance  and  results;  and  (2)  the  next  2  quarters,  indicating  purpose  and 
attendance. 

13.  Life  Cycle  Costs 

Assess  anv  events  since  the  previous  Quarterly  Status  Report  which  might 
significantly  affect  the  life  cycle  costs. 

14.  Assessment  of  the  estimate  to  complete  the  current  program: 

a)  total  program 

b)  prime  contracts ) 

15.  Prime  contract!  s)  changes 


Number  of  contract  changes  approved  in  the  current  quarter  ,  Dollar 
amount _ . 

Number  of  contract  changes  submitted  in  the  current  quarter  but  not 
approved _ . 

Estimated  dollar  amount 


Submitted  by: 


Approved  by: , 


'rogram  Manager 


[Ref.  5:  Attachment  6] 


APPENDIX  F 

STATUS  CODE  DEFINITIONS 


(taken  from  DOT  Order  4200. 14B) 

The  following  criteria  provide  more  specific  guidelines  for  identifying  when  a  program 
is  significantly'  off  target. 

* 

On-target  Status 

1.  Not  more  than  10  percent  off  budget  as  reflected  in  the  operating  plan. 

2.  Within  3-4  weeks  of  meeting  major  nonpublic  milestone  dates  (milestones  to 
which  the  Secretary  has  not  publicly  committed  the  Department). 

3.  Making  acceptable  progress  toward  achieving  objectives  and  performance 
measures,  and  indicating  that  tins  satisfactory  performance  will  continue. 


Management  Attention  Status 

1.  Between  10-20  percent  off  budget  as  reflected  in  the  operating  plan. 

2.  Between  1-3  months  of  meeting  major  nonpublic  milestone  dates. 

3.  Results  indicate  program  may  not  be  able  to  achieve  desired  objective  and 
performance  measures. 

4.  Although  current  status  is  still  on  target,  a  situation  is  developing  that  will  cause 
problems  in  the  future. 

Critical  Status 

1.  Over  20  percent  off  budget  as  reflected  in  the  operating  plan. 

2.  More  than  3  months  behind  meeting  major  nonpublic  milestone  dates  or  behind 
any  milestone  to  which  the  Secretary  has  publicly  committed  the  Department. 

3.  Results  to  date  show  the  program  will  not  meet  desired  objectives  and 
performance  measures  without  budget  or  legislative  relief. 


* 


No  action  required. 


The  Assistant  Secretary  for  Budget  and  Program  shall  advise  the  Acquisition 
Executive  as  appropriate. 

[Ref.  5:  Attachment  6] 


68 


APPENDIX  G 

AGENCY  PROCUREMENT  REQUEST 


1. 


2. 


3. 


4. 


5. 


(taken  from  FIRMR  Sec.  20 1-23. 106-2 > 

Agency  Information:  Provide  agency  name,  address,  and  location  where 
equipment  will  be  installed  or  services  will  be  performed.  Provide  names  and 
telephone  numbers  of  appropriate  technical  and  contracting  officials  identify 
the  position  title  and  organization  identity  of  the  official  authorized  to  conduct 
the  acquisition. 

Project  Title  and  Description: 

a.  Provide  the  project  title  and  a  brief  but  specific  description  of  the  primary 
agency  program!  s)  that  the  ADP  equipment  win  support. 

b.  Provide  a  brief  but  specific  description  of  the -current  major  system 
components  (including  ADPE  configuration)  or  services  supporting  the 
program!  s). 

c.  Provide  a  brief  but  specific  description  of  the  major  system  components  or 
services  to  be  acquired  during  the  systems  life  of  the  requirement.  The 
delegation  resulting  from  this  submission  will  be  limited  to  resources  described 
herein. 

Acquisition  Strategy: 

a.  Indicate  whether  or  not  the  proposed  procurement  approach  is  to  satisfy 
a  requirement  using  a  specific  make  and  model  specification:  whether 
compatibility  limitecT  requirements  will  be  used  on  either  a  mandators  or 
nonmandatdry  basis;  and  specify  the  tvpe  of  contract  expected  to  be  used. 


b.  Identify  bv  fiscal  vear  quarter  the  following  planned  milestones:  Release 
of  solicitation  document  and  contract  award. 


c.  If  the  request  involves  a  pilot  or  prototy  pe, 
implementation  phase  must  be  described. 


the  strategy  for  the  follow  on 


d.  Indicate  whether  the  acquisition  plan  contemplates  contracting  ...  under 
policies  and  procedures  for: 


Full  and  open  competition 

Full  and  open  competition  after  exclusion  of  sources;  or 
Other  than  full  ancf  open  competition. 


Estimated  Contract  Life  and  Cost:  The  estimated  contract  cost  of  the  acquisition 
(not  the  overall  system  life  cost)  shall  be  identified  bv  type  of  request  for  the 
contract  life  and  shall  include  all  anticipated  optional  quantities,  sen  ices,  and 
periods.. .The  estimated  contract  cost  should  correspond  to  the  planned  contract 
life.  The  delegation  of  authority  resulting  from  this  submission  will  be  limited 
to  quantities  and  vears  described  herein. 


Regulatory  compliance: 

a.  (1)  Provide  a  statement  which  indicates  that  the  agency  has  reviewed  and 
complied  (or  will  comply)  with  all  applicable  regulations,  or 
(2)  List  those  deviations  to 'the  regulations  that  applv  to  this  requires  for 
which  approval  is  sought  and  provide  an  explanation  lor  each 
regulatory’  deviation  request. 

b.  Provide  the  date  of  completion  or  most  recent  update  of  the  foilowinc 
documentation,  or  indicate  if  not  applicable: 


(1)  Requirements  analysis 
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(4)  Findings  to  suppprt  the  use  or  compatibility  limited  requirements 

(5)  Software  conversion  study 

(6)  Certified  data  to  support  a  contemplated  requirement  available  from 
only  one  responsible  source 

(7)  Certified  data  to  support  a  contemplated  requirement  using  a  specific 
make  aqd  model  specification 

(8)  Description  of  those  planned  actions  necessarv  to  foster  competition 
Tor  subsequent  procurements 


Analysis  of  Alternatives  „ 

rcnqrmance  evaluation  for  the  currently,  installed  A  DP  system 
Findings  to  suppprt  the  use  of  compatibility  limited  requirements 
Software  conversion  study 


7.  Agency/GSA  references:  Provide  references  to  previous  GSA  authorizations, 
meetings,  telephone  discussions,  etc. 

8.  Agency  authorized  signature,  position  title,  organizational  identity,  date. 

[Ref.  9:  Section  201-23.106-21 


APPENDIX  H 

DETERMINATION  OF  NEED  AND  REQUIREMENTS  ANALYSIS 


(taken  from  FIRMR  Sec.  201-30.007) 

As^jmnimum,  the  agency  shall  consider  the  following  factors  in  the  requirements 

1.  The  information  processing  functions  that  must  be  performed. 

2.  The  agencv  applications,  information  resource  systems,  and  components 
involved,  their  physical  locations,  and  operational  constraints. 

3.  The  problem  that  will  be  solved  by  acquiring  new  or  additional  equipment, 
systems  and/or  software. 

4.  The  nature  of  the  data  or  information  to  be  generated,  transmitted,  or  stored  on 
the  proposed  equipment  or  system,  who  will  maintain  it,  and  who  will  require 
access  to  it. 

5.  The  /easibilitv  of  sharing,  using  reassigned  or  excess  Government- owned  or 
-leased  equipment,  the  ofF-loading  of  lower  priority  applications,  using  Federal 
data  processing  centers  and  GSA  sources  oi  supplv,  using  commercial  ADP 
services,  or  if  applicable,  increasing  the  capability  and  productivity  of  the 
existing  system. 

6.  The  probable  improvement  in  operational  effectiveness  and  the  economies  that 
wl^be  realized  from  acquiring  new  or  additional  equipment,  systems,  and  or 

7.  Space  management  cgnsiderations;  e.g.  heat  dissipation,  air  flow’,  temperature 
range,  relative  humidity,  energy  conservation,  power  supplv,  cables,  including 
coordination  with  building  managers  and  GSA. 

8.  The  present  and  projected  workload  in  terms  of: 

j,  Systems  life; 

ij.  Data  entrv  and  associated  telecommunications  support: 
ju.  Data  base  and  data  base  management; 

iv.  Data  handling  or  transaction  processing  bv  tvpe  and  volume; 

v.  Output  needs  and  associated  telecommunications  support; 

vi.  Expandability  requirements;  and 

vu.  Privacy  and  security  safeguards. 

9.  A  performance  evaluation  of  the  currentlv  installed  ADP  system  to  provide  a 
baseline  for  evaluation  of  proposed  alternatives  for  meeting  the  data  processing 


10.  The  risks  over  the  systems  life  of  adverse  impact  on  agencv  missions  bv 

acquiring  insufTicient  ADPE  capacity  versus  the  extra  costs'  of  acquiring 
excessive  ADPE  capacity.  6 

11.  The  appropriate  performance  and  capability  validation  techniques  that  should  be 
employed  in  the  acquisition. 

[Ref.  9:  Section  201-30.007] 


APPENDIX  I 

COMPATIBILITY  LIMITED  REQUIREMENTS 


( taken  from  FIRMR  Sec.  201-30.009-3) 

The  following  factors  shall,  be  considered  in  determining  whether  the  incorporation  of 

compatibility  limited  requirements  is  justified  for  the  augmentation  or  replacement 

acquisition: 

1.  The  essentiality  of  existing  software,  without  redesign,  to  meet  agencv  critical 
mission  needs;  e.g.,  the  continuity  of  operations  may  be  so  critical  that 
conversion  is  not  a  viable  alternative. 

2.  The.  additional  risk  associated  with  conversion  if  compatibility  limited 
requirements  are  not  used  apd  the  extent  to  which  the  Government  would  be 
injured,  financially  or  otherwise,  if  the  conversion  to  the  new  ADP  system  fails. 

3.  The  additional  adverse  impact  of  factprs  such  as  delay,  lost  economic 
opportunity,  and  less  than  optimum  utilisation  of  skilled  professionals  if 
compatibility  limited  requirements  are  not  used. 

4.  The  steps  being  taken  to  foster  competitive  procedures  in  the  augmentation  or 
replacement  acquisition. 

5.  The  off-loading  of  selected  applications  programs  to  commercial  data  processing 
service  facilities  as  an  alternative  to  conversion. 

6.  The  continuation  of  ADP  services  for  selected  application  programs  with  the 
present  commercial  ADP  services  contractor  as  an  alternative  to  conversion  of 
all  programs  in  the  present  ADP  resource  sy  stem. 

7.  The  extent  of  essential  parallel  operations;  i.e..  the  need  to  continue  operation  of 

the  old  system  in  parallel  with  the  new  svstem  until  the  new  svstcm  can  lullv 
support  the  mission  needs. 

8.  The  feasibility  of  competing  cpnversion  requirements  to  be  performed  on  a 
guaranteed  basis  under  a  solicitation  that  couple?  the  conversion  efiort  and 
ADP  services,  in  a  single  contract,  including  consideration  of  the  basis  for  a 
calculation  of  hquidateo-damages  provisions  for  conversion  performance  failure. 

[Ref.  9:  Section  201-30.009-3] 


APPENDIX  J 
SELECTION  PLAN 


(taken  from  DOT  Order  4200. II A) 

The  Selection  Plan  should  include  the  following: 

a.  A  brief  description  of  the  product  or  service  to  be  procured; 

b.  The  date  of  approval  of  an  applicable  Acquisition  Paper  covering  the  proposed 
procurement; 

c.  Identification  of  any  closely  related  procurements  or  planned  procurements; 

d.  A  brief  description  of  thpse  areas  of  the  procurement  which  are  believed  to 
represent  significant  techmcal,  schedule,  or  cost  risks; 

e.  Nominations  for  stalling  of  the  SEB  bv  individual  name.  Indicate  each 
nominee  s  field  of  specialization  and  iob  title.  Ensure  each  nominee  will  be 
available  to  serve  on  the  SEB  before  submitting  the  Selection  Plan; 

f.  An  estimate  of  the  total  procurement  cost  and  a  statement  of  availabilitv  of 
funds; 

g.  A  statement  of  significant  procurement  considerations,  including  the  proposed 
contract  type,  identification  of  option  items,  anticipated  period  of  performance, 
funding  method,  and  and  unusual  contract  clauses  that  are  contemplated: 

h.  Identification  if  the  product  or  service  to  be  procured  will  be  the  basis  for  future 
standardization; 

i.  A  proposed  milestone  schedule  of  events  leading  up  to  contract  award:  and 

j.  Any  other  information  warranting  the  SSO  s  attention. 

[Ref.  II:  pp.  I- 1,21 


APPENDIX  K 

REQUEST  FOR  PROPOSAL 


( taken  from  DOT  Order  4200.1 1 A) 

In  determining  the  RFP's  acceptability,  for  evaluation  purposes,  the  SEB  should  assure 

that  it  provides  the  following: 

a.  A  statement  of  work  accurately  describing  the  product  or  service  to  be  procured. 

Further,  the  statement  of  work  should  be  consists :  with  the  approved 
Selection  Plan  and  anv  applicable  Acquisition  Paper  1!  the  acquisition  is  a 
major  svstem  subject  to  tne  requirements  ol  DOT  42"<>.  1  \  and  the  approved 
Ar  provides  for  the  solicitation  ol  alternative  system  design  concepts,  the 
Government  s  requirement  should  be  stated  in  terms  oi  mission  need  so  that 
industry’  can  respond  with  alternative  system  design  concepts  to  satisfy  the 
mission  need  and  propose  their  own  technical  approach,  design  features, 
subsystems,  and  schedule  and  cost  goals. 

b.  A  statement  as  to  whether  of  not  a  pre-proposal  conference  is  contemplated.  If 
a  jpre-proposal  conference  is  to  held,  state  when  and  where  and  advise  the 
offerers  tnat  questions  to  be  discussed  at  the  conference  must  be  submitted  in 
writing  bv  a  specified  number  of  davs  prior  to  the  conference.  Sufficient  rime 
must  Be  pemjitted  for  potential  oflerers  to  review  the  RFP  prior  to  anv  pre¬ 
proposal  conference. 

c.  Description  of  the  desired  proposal  format. 

d.  Description  of  the  type  of  contract  that  is  contemplated,  i.e..  cost  reimbursement 
or  fixed  price,  and  anv  special  incentive  or  cost  participation  features.  The  RI  P 
should  include  a  notice  that  although  a  particular  type  of  contract  is 
contemplated,  the  Government  mav  determine  after  evaluation  of  proposals, 
that  another  tvpe  of  contract  is  tpor'e  appropriate  and  mav  award  on  that  basis 
without  soliciting  new  proposals  from  all  oflerers. 

e.  Clear  and  concise  statement  of  the  basis  on  which  the  award  will  be  made.  This 
should  be  followed  by: 

(1)  Complete  description  of  the  technical  evaluation  criteria.  The  technical 
evaluation  criteria  should  be  listed  in  descending  order  of  importance 
with  an  indication,  in  some  narrative  manner,  of  their  relative 
importance. 

(2)  Description  of  the  business  management  evaluation  criteria. 

(3)  Description  of  anv  other  evaluation  criteria  established  bv  the  SEB.  e.g. 
cost. 

f.  When  appropriate,  state  the  number  of  awards  contemplated  or  that  multiple 
awards  may  be  made. 

g.  Proposed  contract  clauses. 


(Ref.  II:  pp.  IV-1.2| 
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